- User Since
- Jul 25 2016, 12:54 PM (218 w, 2 d)
With all of them applied, a 228 KB xdata section shrinks by 74 KB thanks to being able to write packed unwind info, ending up with smaller xdata than the corresponding section for an x86_64 build of the same DLL.
Mon, Sep 28
Awesome, thanks for finding all the relevant cases here. I've tested it with my own testsuite for GNU style weak symbols, and it seems to still be working.
Sat, Sep 26
Fri, Sep 25
I tested this with an input file like this here:
.globl uniquename uniquename: ret
This does seem to produce the right results for all the cases that I can come to think of right now, so I guess it's good, but I'd like to think about it for another day or two, if that's ok.
LGTM overall, one change that seems superfluous though.
Thu, Sep 24
Wed, Sep 23
Tue, Sep 22
Expanded the comment regarding matching/mismatching prologues to include more about the backstory.
Mon, Sep 21
Fri, Sep 18
Thu, Sep 17
This broke a few tests for me (generating code that now gives the fail result at runtime).
Wed, Sep 16
@rnk - Can you follow up on the discussion above?
Tue, Sep 15
The file that shows the error can be built from https://martin.st/temp/eval.c, built as clang -target armv7-w64-mingw32 -c -O2 eval.c.
The main difference in code, in the function that show the error in one of the testcases that broke, looks like this:
- movs r1, #9 - cmp r0, #9 - it lt - movlt r1, r0 - bic.w r0, r1, r1, asr #31 + usat r0, #1, r0
Mon, Sep 14
Headsup: This broke a number of tests for me. Looking closer into where it changed things erroneously...
Pushed this one now.
Sun, Sep 13
The commit description talks about making the caching optional, but I don't really see that aspect in the patch - or maybe I'm just not studying it closely enough?
The change itself looks good to me, but the comment in lit.site.cfg.in does look confusing to me as well, so it'd be great to have it reworded.
Sat, Sep 12
Ok, so if I read code correctly, the suffix gets added here: https://github.com/llvm/llvm-project/blob/9c651c231f3144f53e13cd0a1747589e1b2edccd/llvm/cmake/modules/AddLLVM.cmake#L599-L606
LGTM then! Can apply it a bit later.
Fri, Sep 11
This should be ok, I think.
Does the static lib built in this case include any dllexport attributes (that can cause issues if linking it statically into another DLL)?
If the corresponding DLLs built in MSVC mode actually have a version number suffix, should we change the build for MinGW mode to include a number as well? Or is any of the relevant DLLs ever built in MSVC mode at all?
Removed superfluous "sub sp, sp, #0".
This looks good to me! I can push it later.
What's the practical effect of this? I see that a number of libraries already have a lib prefix prepended, like libclang/liblldb - I presume this changes the name of the individual libs (for BUILD_SHARED_LIBS=TRUE configurations)?