Zhou, David(ChunMing) via llvm-dev
2020-Apr-28 05:39 UTC
[llvm-dev] llvm-dev Digest, Vol 190, Issue 135
[AMD Public Use]
Can I receive dev emails directly? Don't like this style.
-David
-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of via
llvm-dev
Sent: Tuesday, April 28, 2020 11:58 AM
To: llvm-dev at lists.llvm.org
Subject: llvm-dev Digest, Vol 190, Issue 135
Send llvm-dev mailing list submissions to
llvm-dev at lists.llvm.org
To subscribe or unsubscribe via the World Wide Web, visit
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675253943&sdata=88v9yUPwJ6qY4cNhB4fyXCixmrWPIWEUfiMaP316TqY%3D&reserved=0
or, via email, send a message with subject or body 'help' to
llvm-dev-request at lists.llvm.org
You can reach the person managing the list at
llvm-dev-owner at lists.llvm.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of llvm-dev digest..."
Today's Topics:
1. How to get branch coverage by using 'source-based code
coverage' (LoveZhi Xie via llvm-dev)
2. Re: C++ JIT Compiler with LLVM on Windows 10 - part 5
(Emmanuel Roche via llvm-dev)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Apr 2020 00:35:33 +0800
From: LoveZhi Xie via llvm-dev <llvm-dev at lists.llvm.org>
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] How to get branch coverage by using 'source-based
code coverage'
Message-ID:
<CAE9TZfa+6MBZJJj1KddXsvUkQmNPHJXbxbspg5zA6DOUiO3Kig at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi, llvm/clang experts
I need to get the branch coverage for some testing code. But i found gcov
can't give a expected coverage which may count some 'hidden branch'
in (See stackoverflow answer
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F42003783%2Flcov-gcov-branch-coverage-with-c-producing-branches-all-over-the-place&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675253943&sdata=ET6pcxHHlmmVY6zCriMvzBqQiutXXpn3IrjnJ9AM1Uw%3D&reserved=0>).
Instead, I turn to use clang and the 'source-based code coverage'
feature may be a right choice. But i can't find anything to describe branch
coverage explicitly on the official site
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclang.llvm.org%2Fdocs%2FSourceBasedCodeCoverage.html&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675253943&sdata=bEZWlm5Okwi72g6iMFLji7hI8NMtwTELinRnMIPFAd0%3D&reserved=0>.
So how to use clang to get branch coverage by utilizing
'source-based...'
feature? And is *region coverage *equivalent to branch coverage?
(I tested on a simple program and region coverage seems pretty close to branch
coverage)
Any help is highly appreciated
Thanks,
Ted Xie
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2Fattachments%2F20200427%2Fd9aad1e1%2Fattachment.html&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675253943&sdata=T7KVqM0T%2Bcr26Z7FGDaYBxFNyRbPW42KiIJhPmbWf6g%3D&reserved=0>
------------------------------
Message: 2
Date: Tue, 28 Apr 2020 05:35:07 +0200
From: Emmanuel Roche via llvm-dev <llvm-dev at lists.llvm.org>
To: Lang Hames <lhames at gmail.com>
Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] C++ JIT Compiler with LLVM on Windows 10 -
part 5
Message-ID:
<CAC0fJsx3L1d7yNa8QEtCJ_QmHMr=fYwiTEDcFvkUgN1GBRAgCw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Lang,
Thank you for your feedback on the blog post, please find below some additional
inputs from my side on the comments you provided:
> Regarding emulated TLS deactivation: I've never looking into
> how/whether
this works on Windows. If it doesn't make sense to have it on by default
there we can change the default for Windows targets.
I'm really no expert, so you probably want to collect additional
inputs/checks on this point, but yes, from my current perspective, it seems that
it doesn't really work to try to use Emulated TLS in LLJIT on Windows, but
one should keep in mind that this is when using the microsoft crt from Visual
Studio (FYI, I'm using version 2017 for now, maybe it was different in
previous versions too): I would expect things to be different if you are using
another compiler as base (?) [I mean, if you change the default, this might then
break previously working code that was based on mingw for instance... But not
sure if this should be a concern or not for a not yet released version of LLVM
;-)]
> I think that anything that llvm-link can merge should, in theory, be
> safe
to add to the JIT. This actually sounds like a bug. Are you able to share the
full modules that you were merging?
Initially, the test I made on this point was using the Lest test framework as
described in my post, but your feedback above got me thinking, and I could
actually come up with a more simple setup without any C++ library
dependency: this new test is simply based on a couple of C++ functions that are
using exceptions. I used the attached lua script "exception3.lua" to
generate the bitcode files and load the corresponding modules [of course I
don't expect you to run lua scripts, but I thought that this could help
understanding the code generation context anyway]. So with that script I
generated the test_func1.bc/test_func2.bc/test_func1_and_func2.bc and the
corresponding .ll file (generated from the .bc files using llvm-dis): all those
files are attached to this email too.
=> So, I can load for instance the module corresponding to test_func1.bc in
my main JITDylib, but then, if I try to load the test_func2 IR module in the
same Dylib, I get the following error:
*Duplicate definition of symbol '??_7exception at std@@6B@'*
In all the .ll files you will find multiple references of that symbol...
but unfortunately, my skills won't get me any further than that [=> ie. I
have no idea what to think about the content of those files :-)].
But anyway, if you notice anything interesting yourself, or you have an idea you
think I should try, or you need more info on anything here please let me know.
PS: I'm thinking maybe the command line arguments I'm providing to the
compilerInvocation might also be important here so, just in case: here is the
list of args I'm using currently:
{ "-triple=x86_64-pc-windows-msvc19.16.27030",
"-x", "c++",
"-mrelax-all",
"-mincremental-linker-compatible",
"-disable-free",
"-discard-value-names",
"-mrelocation-model", "pic",
"-pic-level", "2",
"-mthread-model", "posix",
"-mframe-pointer=none",
"-relaxed-aliasing",
"-fmath-errno",
"-fno-rounding-math",
"-mconstructor-aliases",
"-munwind-tables",
"-target-cpu", "x86-64",
"-mllvm",
"-x86-asm-syntax=intel",
"-stack-protector","2",
"-fcxx-exceptions",
"-fexceptions",
"-fexternc-nounwind",
"-fms-volatile",
"-fdiagnostics-format", "msvc",
"-dwarf-column-info",
"-Wall",
"-std=c++17",
"-fdeprecated-macro",
"-ferror-limit","19",
"-fmessage-length=174",
"-fms-extensions",
"-fms-compatibility",
"-fms-compatibility-version=19.16.27030",
"-fdelayed-template-parsing",
"-fcolor-diagnostics",
"-fobjc-runtime=gcc",
"-faddrsig",
}
Regards,
Manu.
Le lun. 27 avr. 2020 à 20:41, Lang Hames <lhames at gmail.com> a écrit :
> I was just reading the blog post -- very cool!
>
> Regarding Globals construction & destruction: There definitely has
> been a lot of churn in that area. There will probably be more before
> LLVM 11 is released, but I can see light at the end of the tunnel. I
> think the Right Way to run initializers in a JITDylib is to treat it
> as equivalent to a dlopen operation (with extra allowances for the
> fact that new initializers can be added to a JITDylib at runtime).
> This is what the LLJIT::initialize method is doing. Now we just need
> to generalize it to support out-of-process JITs. That will at least
> require a new remote-target abstraction, and an RPC implementation for
testing in-tree.
>
> Regarding emulated TLS deactivation: I've never looking into
> how/whether this works on Windows. If it doesn't make sense to have it
> on by default there we can change the default for Windows targets.
>
> Regarding merging of multiple modules:
>
> "But of course this would not work because as soon as I try to load
> the second script, I get a duplicate symbol error from LLVM (and this
> completely makes sense):
>
> [ERROR]: LLVM error: Duplicate definition of symbol
> '??_7success at lest@@6B@ '"
>
> I think that anything that llvm-link can merge should, in theory, be
> safe to add to the JIT. This actually sounds like a bug. Are you able
> to share the full modules that you were merging?
>
> Regards,
> Lang.
>
>
> On Mon, Apr 27, 2020 at 11:11 AM David Blaikie <dblaikie at
gmail.com> wrote:
>
>> +Lang for LLVM Orc things
>>
>> On Mon, Apr 27, 2020 at 3:34 AM Emmanuel Roche via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hello LLVM developers!
>>>
>>> So, I'm continuing my journey with my toy C++ JIT compiler
>>> implementation, and I wrote another article on the issues/solutions
>>> I've been working on in the past few days, mainly:
>>>
>>> - Precompiled header handling,
>>> - Emulated TLS desactivation,
>>> - Globals construction & destruction,
>>> - C++ exceptions handling,
>>> - Multi modules linking,
>>>
>>> => In case this could be helpful to anyone, you will find this
>>> article
>>> here:
>>>
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwik
>>>
i.nervtech.org%2Fdoku.php%3Fid%3Dblog%3A2020%3A0425_jit_compiler_par
>>>
t5_improvements&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d
>>>
1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7
>>>
C637236431675263940&sdata=bcwX4KPDsTc3k%2BocDXgDk%2FCTbu9sTA%2Bb
>>> 3fh8Zl3QCoc%3D&reserved=0
>>>
>>> And of course, if you have any questions for me, just let me know.
>>>
>>> Meanwhile, happy hacking everyone ;-)!
>>>
>>> Best regards,
>>> Manu.
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
>>>
sts.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=02%7
>>>
C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd
>>>
8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675263940&sdata
>>>
=NpOL9QDxVBQnr6MrYHwd%2Frc34Pv87RX%2BeQSbM1DeLcQ%3D&reserved=0
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2Fattachments%2F20200428%2F53a72094%2Fattachment.html&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675263940&sdata=MH9F94SaBM%2BS6iz20vIWgu9Zv5aRrTVrjqJ4AbuBFes%3D&reserved=0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_func1_and_func2.bc
Type: application/octet-stream
Size: 25476 bytes
Desc: not available
URL:
<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2Fattachments%2F20200428%2F53a72094%2Fattachment.obj&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675263940&sdata=syHbT7v%2BjXrIK78LPhtYFuJQNISovT9qCwxHngwpig0%3D&reserved=0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_func2.bc
Type: application/octet-stream
Size: 22448 bytes
Desc: not available
URL:
<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2Fattachments%2F20200428%2F53a72094%2Fattachment-0001.obj&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675263940&sdata=YHeF8xWfon0oYEppNsU2m57uC%2BQwo%2F63BsiaOisiSM0%3D&reserved=0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_func1.ll
Type: application/octet-stream
Size: 68050 bytes
Desc: not available
URL:
<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2Fattachments%2F20200428%2F53a72094%2Fattachment-0002.obj&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675263940&sdata=E8TpzoX0BS8Mh8xvfM9fJBqaGgpgec%2BvIsgc%2FBmitdo%3D&reserved=0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_func1_and_func2.ll
Type: application/octet-stream
Size: 85765 bytes
Desc: not available
URL:
<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2Fattachments%2F20200428%2F53a72094%2Fattachment-0003.obj&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675263940&sdata=rcUh9%2BTBRZplm9WrPj5CM%2Fh38HgXnLgsKqGPfRAokDI%3D&reserved=0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_func1.bc
Type: application/octet-stream
Size: 22404 bytes
Desc: not available
URL:
<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2Fattachments%2F20200428%2F53a72094%2Fattachment-0004.obj&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675263940&sdata=f57v3FHf5vWNdzf%2BMwiiDtcgVGDOXy%2Bgp462NYEAgog%3D&reserved=0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_func2.ll
Type: application/octet-stream
Size: 69361 bytes
Desc: not available
URL:
<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2Fattachments%2F20200428%2F53a72094%2Fattachment-0005.obj&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675263940&sdata=tAq0wnKWacoFbhHy38OvEVm1VpZpAZ0cSWouxBeOQEQ%3D&reserved=0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exception3.lua
Type: application/octet-stream
Size: 1687 bytes
Desc: not available
URL:
<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2Fattachments%2F20200428%2F53a72094%2Fattachment-0006.obj&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675263940&sdata=LRstlcg6omFOqbtXgj0OKZjTXb%2Bq7pQ5oBiyWXKM3k4%3D&reserved=0>
------------------------------
Subject: Digest Footer
_______________________________________________
llvm-dev mailing list
llvm-dev at lists.llvm.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=02%7C01%7Cdavid1.zhou%40amd.com%7C3fcbd237d1374b67c47e08d7eb288767%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637236431675263940&sdata=NpOL9QDxVBQnr6MrYHwd%2Frc34Pv87RX%2BeQSbM1DeLcQ%3D&reserved=0
------------------------------
End of llvm-dev Digest, Vol 190, Issue 135
******************************************