Fri, Oct 18
Thu, Oct 17
I think this looks pretty good, thanks! I really only noticed style nits. I think with some small fixes, we should go ahead and merge it. If you want, I can commit it on your behalf, but I know there are other folks at Microsoft with commit access to LLVM, if you'd prefer. When you upload the next diff, make sure to use the merge point with origin/master as the base, so that the patch will apply cleanly.
Thanks for putting up with these micro-optimized data structures, sorry they're opaque.
It seems like this still broke a buildbot. @rnk, as it's your bot, can you look into it before we revert this? The logs don't really show enough detail... http://lab.llvm.org:8011/builders/sanitizer-windows/builds/53114/steps/stage%201%20check/logs/stdio
I guess the productive thing to do would be for me to put together a patch to CodingStandards and then send it to llvm-dev to get some feedback, and then follow up myself here.
Wed, Oct 16
I tried to get clang to make llvm.powi from C, but it was challenging. Setting -fno-math-errno was what ended up mattering, and even then, I couldn't go from llvm.pow.f64 to powi.
Tue, Oct 15
Mon, Oct 14
I looked at some of the converted cdb tests, and it looks pretty nice. Thanks for working on this! :)
For maintenance reasons, I'd really prefer it if we could find a way to reuse the existing code that calls an external stack probe function. What do you think about taking a look at X86RetpolineThunks.cpp and doing something similar to that? Basically, when the user sets -fstack-clash-protection, LLVM will emit a small comdat+weak function into every object file that has the same ABI as the existing stack probe mechanism. For other prior art, you can also look at how __clang_call_terminate works.
Q: Why should appendToGlobalCtors take a Function * in the first place?
Looks good, amusing. :)
Based on what we learned in https://llvm.org/PR43530, I think we still want to use the location of the call site and not line zero. :(
This makes sense to me, we should be able to replace isIndirect with DW_OP_deref.
Fri, Oct 11
I guess the commit message shouldn't say "[CodeView] Add option to disable inline line tables." It's really an option for all debug info. You could put "[DebugInfo]" on there, or just drop the tag.
I looked into these tests, and it seems that they would've failed if it were not for Python's universal newline translator thing. When I diff the files in question with gnu diff from git bash, they appear to be different without -w or --strip-trailing-cr. So, your fix makes lit's diff more like gnu diff, and fixes the tests to work in that mode.
Thu, Oct 10
Go for it.
Looks very good. :)
Wed, Oct 9
I think the old VS Express editions used to exclude atlmfc, so there's the possibility that we'll be searching non-existent directories, but I think that's OK. Whoever wrote this code was probably basing it on what VS express did. That edition is long gone, and we're better off with this new logic.
- Fix GNUG, tighten tests for it
- add docs, release note
- keep __EXCEPTIONS if !ms
- keep private_extern if !ms
- set GNUG value with flag
Tue, Oct 8
From a big-picture perspective, I would like us to move to treating MS and GNU extensions in the same way (at the cc1 level) to the extent that we can. I think this moves us in that direction.
I'm guessing you've tested with Python 2.7 and 3.5, and that's probably what matters.
Maybe a dumb idea: can we compute the table with constexpr evaluation? You could set up a constexpr function that returns a struct that wraps the array, and then the body of the function would construct the array imperatively as the old initialization code did. Set up a constexpr global with an initializer that calls the function.
Mon, Oct 7