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

101–110 of 111 posts

Re: LLVM 9.0

#101

Post by cryptonector »

jcranmer wrote: post #44
cryptonector wrote: post #24

Earlier quoted context omitted.

That's not what I got from the quoted paragraph. I'll have to chase the links to be sure.

In LLVM terms, it's referring to these kinds of stores: @vval = constant double 1.0, align 8 define void @foo(double *val) { store double %val, double @cval, align 8 | At the LLVM level, the "const" qualifier to pointers and other non-global values get reflected nowhere in the type system. But if you declare a const global variable, that variable gets placed in a read-only data section.

Got it. Thanks!

Re: LLVM 9.0

#102

Post by danalbert »

pjmlp wrote: post #85
ndesaulniers wrote: post #80

Earlier quoted context omitted.

A lot of my teammates focus on LLVM for Android, including the NDK, which redistributes AOSP LLVM. > what is missing versus Java/Kotlin. I'd be happy to pass on feedback, though as worded I'm not sure if you're referring to language features or what exactly?

As mentioned already a couple of times with online discussions with Dan and AMA on Reddit, from me and others: An NDK version of Android JetPack/AndroidX, for starters proper C++ API, instead of forcing everyone to code 90's style, each re-creating their own C++ wrappers for the Android C++ APIs exposed as C function calls. Which by the way, given the whole security theme on Android, means more insecure code than if…

> C++ libraries etc

We do have limited resources, so we have to prioritize what gets done first. We couldn't have provided good C++ APIs before we were even able to provide good C++. We now do provide a pretty good C++ language experience, but this is still not at the top of the todo list. No one else I've spoken to thinks this is more important than the other work we're doing.

> Actually provide build infrastructure to create NDK libraries that can be shared across Android projects, instead of forcing us to somehow cram library and header files into AAR packages while having build scripts extract them for correct placement where cmake and ndk-build expect to find them. cdep never went anywhere, while conan and vcpkg aren't the right answer when many NDK libraries need Java code to come along due to JNI wrappers for like 90% of Android APIs.

This is what I've been working on for most of the year.

> like how long it took to fix the header files

This only took a single release (the rest of the time was to give users a chance to transition), and we did plenty of other things in the same release, so I'm not sure what you're getting at.

> Easier CMake support for multiple libraries on our projects, which is found lacking versus how easy it is on ndk-build.

Not sure what you mean here, but it sounds like CMake is what you don't like? Just use ndk-build then.

Re: LLVM 9.0

#103

Post by ndesaulniers »

BurningCycles wrote: post #96
ndesaulniers wrote: post #72

Earlier quoted context omitted.

Android and CrOS have not had stability issues related to the compiler since switching to Clang. And Phoronix didn't send me any reports; I reached out to Michael and he said he'll send them to me next time he tries.

I was referring to the problems in said benchmark test on Phoronix, where Michael stated: 'The main culprits were Blender and GeekBench 5 causing the Clang-built kernel to cause the system to reset during testing while this behavior wasn't seen when the kernel was built under GCC, so likely some problematic code generation on the Clang side.'

Sometimes its a compiler code gen related bug, sometimes its bad source code. Without a dmesg+vmlinux, it's just anecdata.

Re: LLVM 9.0

#104

Post by pjmlp »

danalbert wrote: post #102
pjmlp wrote: post #85

Earlier quoted context omitted.

As mentioned already a couple of times with online discussions with Dan and AMA on Reddit, from me and others: An NDK version of Android JetPack/AndroidX, for starters proper C++ API, instead of forcing everyone to code 90's style, each re-creating their own C++ wrappers for the Android C++ APIs exposed as C function calls. Which by the way, given the whole security theme on Android, means more insecure code than if…

> C++ libraries etc We do have limited resources, so we have to prioritize what gets done first. We couldn't have provided good C++ APIs before we were even able to provide good C++. We now do provide a pretty good C++ language experience, but this is still not at the top of the todo list. No one else I've spoken to thinks this is more important than the other work we're doing. > Actually provide build infrastructure…

Thanks for jumping in.

So it is really a matter of not having the same resources as Java/Kotlin teams.

Thanks for the update on possible NDK library management.

Regarding the headers, what I am getting at, is why it was such a big issue to fix them, instead of being proper from the start, like other OSes, including embedded ones.

Anyway, thanks for improving the experience versus what it used to be in the early NDK releases.

Re: LLVM 9.0

#105

Post by bumblebritches5 »

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.

Inline assembly is part of the C11 standard as Asm("assembly goes here")

Re: LLVM 9.0

#106

Post by yjftsjthsd-h »

pnako wrote: post #60
wodenokoto wrote: post #54

Earlier quoted context omitted.

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).

This would particularly make sense since it's effectively what they did with GCC for years.

Re: LLVM 9.0

#107

Post by yjftsjthsd-h »

ndesaulniers wrote: post #69
steeleduncan wrote: post #25

Earlier quoted context omitted.

Fuschia seems to be non-GPL. Are Google trying to remove GPL entirely from Android?

I am removing GCC/binutils from Android. I wrote: https://android.googlesource.com/platform/prebuilts/clang/ho... It has nothing to do with GPL. It has everything to do with Google having 50+ LLVM developers and 0 GCC/binutils developers.

Surely that's just a layer of indirection over whatever the real reason is? What prevents Google from having GCC/binutils developers on staff (whether by hiring or training)?

Re: LLVM 9.0

#108

Post by ndesaulniers »

yjftsjthsd-h wrote: post #107
ndesaulniers wrote: post #69

Earlier quoted context omitted.

I am removing GCC/binutils from Android. I wrote: https://android.googlesource.com/platform/prebuilts/clang/ho... It has nothing to do with GPL. It has everything to do with Google having 50+ LLVM developers and 0 GCC/binutils developers.

Surely that's just a layer of indirection over whatever the real reason is? What prevents Google from having GCC/binutils developers on staff (whether by hiring or training)?

Supporting one toolchain is already a ton of work; splitting resources between two toolchains is too costly, even for Google. If you don't think so, you underestimate the cost.

Re: LLVM 9.0

#109

Post by account42 »

moefh wrote: post #34
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:…

I think it will break a lot less code than you think. The C standard has a subtlety with regards to const in that it allows you to (for example) cast away the const-ness of a pointer and use it to write to it, as long as the original memory was not const (i.e., it was gratuitously cast to const). That's used by a lot of code, and LLVM still respects that. This optimization (AFAIK) only removes stores that are disallo…

You can have const variables on the stack. Those will not have hardware write protection but it's still undefined to write to them.

Re: LLVM 9.0

#110

Post by account42 »

ndesaulniers wrote: post #70
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:…

So I've been bitten by this twice already, including just today. 1. This was the last bug preventing us from booting a MIPS Linux kernel. 2. An out of tree MediaTek display driver in Android was causing a kernel panic. To be clear, this is explicitly undefined behavior in C. But this optimization to me feels like semantics from C bleeding into LLVM IR a little.

It's hardly C semantics that const memory should not ever be written to, otherwise there would be no need for the distinction at the LLVM ir level.
Post reply on HN