Displaying 3 results from an estimated 3 matches for "callee1".
Did you mean:
callee
2020 Mar 28
2
[RFC] Replacing inalloca with llvm.call.setup and preallocated
...le, but it seems like asking for bugs. What should the backend
do when it detects two preallocated calls with different layouts? Let's
imagine LTO is promoting one indirect call that uses call.setup into
several direct calls. The IR would look like this:
%cs = call.setup
switch i32 %callee ...
callee1:
call void @callee1(i32 %x, %struct.Foo* preallocated(%struct.Foo) %foo)
br label %rejoin
callee2:
call void @callee2(i32 %x, %struct.Foo* preallocated(%struct.Foo) %foo)
br label %rejoin
rejoin:
...
A logical next step would be to run DAE. Suppose one callee does not use
i32 %x above. N...
2020 Jan 28
2
[RFC] Replacing inalloca with llvm.call.setup and preallocated
On Mon, Jan 27, 2020 at 4:31 PM Eli Friedman <efriedma at quicinc.com> wrote:
> I assume by “drop support”, you mean reject it in the bitcode reader/IR
> parser? We can’t reasonably support a complex feature like inalloca if
> nobody is testing it. If we can’t reasonably upgrade it, and we don’t think
> there are any users other than clang targeting 32-bit Windows, probably
2018 Nov 08
4
LLVM Call Graph may not cover all calls
Hi there,
I am working with opt-6.0 and try to generate a call graph of
libsndfile, but it seems the call graph doesn't cover all call relationship.
Actually, I am doing static analysis on *CVE-2014-8130*, which is a zero
division on libtiff/tif_write.c TIFFWriteScanline. (see
https://security-tracker.debian.org/tracker/CVE-2014-8130)
Theoretically, the main function in