Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLVM 9.0

lists.llvm.org

Post reply on HN
Print view View original

51–60 of 111 posts

Re: LLVM 9.0

#51

Post by Someone »

tedunangst wrote: post #27
Someone wrote: post #13

Earlier quoted context omitted.

memcmp has to find the first offset where the buffers differ, and check which of them is larger. bcmp only has to figure out whether the buffers differ. It doesn’t have to figure out where they differ. For example, for s=1024 , bcmp can do (at most) 128 64-bit compares (using vector registers, it could even use larger steps) memcmp could do the same, with an additional “figure out where in the last 8-byte parts compa…

This would be true, except bcmp has been removed from posix some years ago. There's no particular requirement that a function called bcmp does what you expect.

http://releases.llvm.org/9.0.0/docs/ReleaseNotes.html#notewo...:

”The optimizer will now convert calls to memcmp into a calls to bcmp in some circumstances. Users who are building freestanding code (not depending on the platform’s libc) without specifying -ffreestanding may need to either pass -fno-builtin-bcmp, or provide a bcmp* function.”*

So, he’s, you may have to provide it yourself. I expect you can fairly easily copy-paste it from various BSD-licensed libraries, though (example: https://github.com/freebsd/freebsd/blob/master/sys/libkern/b..., but be warned about that “I don't believe this is a problem since AFAIK, objects are not protected at smaller than longword boundaries”. That likely is, but may not be true on your platform)

Re: LLVM 9.0

#52

Post by tedunangst »

saagarjha wrote: post #50
tedunangst wrote: post #27

Earlier quoted context omitted.

This would be true, except bcmp has been removed from posix some years ago. There's no particular requirement that a function called bcmp does what you expect.

The compiler will surely use a (most likely intrinsic) function with appropriate semantics in that case.

The release notes go on to say that you may need to provide your own implementation of bcmp, which does not sound very intrinsic.

Re: LLVM 9.0

#53

Post by saagarjha »

tedunangst wrote: post #52
saagarjha wrote: post #50

Earlier quoted context omitted.

The compiler will surely use a (most likely intrinsic) function with appropriate semantics in that case.

The release notes go on to say that you may need to provide your own implementation of bcmp, which does not sound very intrinsic.

Huh, interesting. I was assuming that the compiler would statically link in a bcmp in that case, but it looks like it will literally replace it with a call to bcmp in certain cases (as defined by the remainder of that point in the release notes). Apparently this was brought up and brushed aside as not an issue: https://bugs.llvm.org/show_bug.cgi?id=41035

Re: LLVM 9.0

#54

Post by wodenokoto »

brynet wrote: post #26

Note that this release (9.x) marks the first to be no longer available under the original permissive NCSA (BSD-like) LLVM license, going forward the LLVM project has moved to an "Apache 2.0 with LLVM Exceptions" for everything. And not just the compiler itself, but also sub-projects like the supporting libc++/libc++abi standard libraries. This change only happened due to corporate pressure, and was done without consi…

As someone completely out of the loop:

Are openBSD switching compiler? Are they doing a fork from the 8 version?

How was code relicensed in the first place?

Re: LLVM 9.0

#55

Post by mrmonkeyman »

cesarb wrote: post #20
colechristensen wrote: post #14

Earlier quoted context omitted.

Can anyone give a good concise explanation as to why GOTO was not in LLVM from the beginning? It seems like something quite obvious to need. I can only guess that it had something to do with their compliation strategy not being able to deal with the ... nonlinearity* ... introduced by GOTO. *Probably a better word for that

This is not about "goto", it's about "asm goto", which is a gcc extension which allows inline assembly (itself a gcc extension) to jump to a label outside the inline assembly.

Also known as "awesome goto".

Re: LLVM 9.0

#56

Post by tedunangst »

Someone wrote: post #51
tedunangst wrote: post #27

Earlier quoted context omitted.

This would be true, except bcmp has been removed from posix some years ago. There's no particular requirement that a function called bcmp does what you expect.

http://releases.llvm.org/9.0.0/docs/ReleaseNotes.html#notewo... : ”The optimizer will now convert calls to memcmp into a calls to bcmp in some circumstances. Users who are building freestanding code (not depending on the platform’s libc) without specifying -ffreestanding may need to either pass -fno-builtin-bcmp, or provide a bcmp* function.”* So, he’s, you may have to provide it yourself. I expect you can fairly eas…

So the problem here is I may already have a function in my program called bcmp, which takes no arguments and prints "better consider more possibilities" to standard output. This is all fine and legal. My program also uses memcmp, because of course it does. But now calls to memcmp are going to be replaced to with calls to bcmp, which does not have the same effect at all.

Re: LLVM 9.0

#57

Post by BurningCycles »

cormacrelf wrote: post #15
KindOne wrote: post #8

Repo of the Linux kernel built with clang: https://github.com/ClangBuiltLinux/linux

"This branch is even with torvalds:master." Does that mean there are no patches necessary for any GCC builtins? Or does the actual clang-buildable part live on another branch?

Yes, there are still some stability issues though. Phoronix benchmarked the Linux kernel built with Clang/LLVM against GCC recently: https://www.phoronix.com/scan.php?page=article&item=clang-li...

Re: LLVM 9.0

#58

Post by rurban »

cryptonector wrote: post #18

> LLVM will now remove stores to constant memory (since this is a contradiction) under the assumption the code in question must be dead. This has proven to be problematic for some C/C++ code bases which expect to be able to cast away ‘const’. This is (and has always been) undefined behavior, but up until now had not been actively utilized for optimization purposes in this exact way. For more information, please see:…

Optimizing away even more calls of memset, memcpy or memmove is the completely wrong way. gcc went down this bug and called it "optimization", now llvm did the same. Can we at least keep at least one sane working compiler? At least emit a prominent warning when "optimizing" away lib calls. This helps only artificial benchmarks and will hurt everybody.

If an assignment to const memory is illegal, treat it as error, and don't silently remove it.

Fear we'll have to blacklist clang-9 also, not just gcc-9.

Re: LLVM 9.0

#59

Post by drdrey »

colechristensen wrote: post #14
lpage wrote: post #3

> "Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang" This is big. Support for asm goto was merged into the mainline earlier this year, but now it's released [1]. Aside from the obvious implications of this - being able to build the kernel with LLVM - working with eBPF/XDP just got way easier [2]. [1] https://github.com/llvm/llvm-project/commit/784929d0454c4df6... [2]…

Can anyone give a good concise explanation as to why GOTO was not in LLVM from the beginning? It seems like something quite obvious to need. I can only guess that it had something to do with their compliation strategy not being able to deal with the ... nonlinearity* ... introduced by GOTO. *Probably a better word for that

re: nonlinearity, I believe the word is irreducibility (https://en.wikipedia.org/wiki/Control-flow_graph#Reducibilit...)

Re: LLVM 9.0

#60

Post by pnako »

wodenokoto wrote: post #54
brynet wrote: post #26

Note that this release (9.x) marks the first to be no longer available under the original permissive NCSA (BSD-like) LLVM license, going forward the LLVM project has moved to an "Apache 2.0 with LLVM Exceptions" for everything. And not just the compiler itself, but also sub-projects like the supporting libc++/libc++abi standard libraries. This change only happened due to corporate pressure, and was done without consi…

As someone completely out of the loop: Are openBSD switching compiler? Are they doing a fork from the 8 version? How was code relicensed in the first place?

For them to switch (which is a lot of work), there would have to be an alternative to switch to.

So it looks like they'll keep using 8 in the base system, i.e. maintain a de-facto fork (and probably provide 9 through ports).

Post reply on HN