User Details
- User Since
- Apr 18 2013, 6:48 AM (404 w, 2 d)
Yesterday
So I'm wondering, if I remove the above setAssemblerDialect line and revert this commit, we should have inline asm (both module-level and GNU function-leve) respect the target-selected asm dialect variant both for ThinLTO and non-ThinLTO, so they should match again. Would that also solve the problem you were originally tracking?
Thu, Jan 14
Based on @hans 's feedback, I added a new enumeration kind called RelOffsetArrayKind, and remove IsRelative flag.
This separates the lookup table and relative lookup table IR generation.
Do you think this helps for the abstraction?
I feel like if it might be better if we can generate the relative lookup table in the first place instead of generating it in a separate pass.
Tue, Jan 12
Great stuff, thanks for working on this!
Mon, Jan 11
Fri, Dec 18
Looks great, thanks!
Dec 9 2020
Dec 8 2020
Dec 7 2020
Dec 3 2020
lgtm
Dec 2 2020
Dec 1 2020
Moving the "Append the module inline asm string" code down, and simplifying it in the process.
Adding test case where the symver doesn't get imported.
lgtm
I just realized this makes Linker/ depend on Object/
I'm not sure whether that's a problem or not, but we could avoid that by storing the symvers in a metadata node again.
Pulling in the symver directives in IRLinker::run() instead. (I didn't do a separate function since it's just a few lines, but happy to do that if you think it would be better.)
Seems like a good idea to me.
Nov 30 2020
Nov 27 2020
Seems reasonable to me, but someone who actually knows clang-scan-deps should take a look too.
Nov 24 2020
Nov 23 2020
Thanks for the pointers!
(I added a naming comment, but feel free to resolve that as you feel is best.)
lgtm, probably check with maskray that he's happy first though.
Nov 17 2020
Nov 16 2020
For Chromium, the latest patch seems to fix the issues we saw. Thanks!
Making the tarballs more reproducible sounds great.
Nov 13 2020
The test fails on Mac, see e.g. https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8863756117615904432/+/steps/package_clang/0/stdout
Nov 12 2020
I don't think it makes sense to try to emit the closure until we have the ctor definition. I'll update the patch to handle this.
Ok. That's a bit different than what MSVC is doing. It generates a closure constructor even if there is only a declaration. But I guess we are not aligning specifically with MSVC!
Look good.
Nov 11 2020
Nov 10 2020
Handling the decl only case.
clang.exe -c test.cpp
Assertion failed: !hasUninstantiatedDefaultArg() && "Default argument is not yet instantiated!", file D:\IUSERS\zahiraam\llorg_ws\ws1\llvm\clang\lib\AST\Decl.cpp, line 2719
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Nov 9 2020
I was looking into this today, and sent out what I think is a better approach: https://reviews.llvm.org/D91089
Please take a look.
Addressing comments.
Nov 5 2020
Nov 4 2020
I'm not sure ignoring these is the right thing to do. Maybe they should be "Unsupported but parsed options" instead?
lgtm
lgtm
lgtm
Nov 3 2020
Sorry for the late follow-up, but this caused big problems in Chromium.
Nov 2 2020
Oct 30 2020
Looks reasonable to me.
Oct 29 2020
Oct 28 2020
lgtm thanks!
Thanks for fixing, but can you please elaborate a little since I'm not familiar with the details here:
Oct 20 2020
Oct 19 2020
Follow-up to fix the Windows build, https://github.com/llvm/llvm-project/commit/a7acee89d68473183cc5021d952a56cdf0ae27d3
This broke Chromium's build, causing it to fail with
"Cannot pop empty stack!" from one of the backend passes.