similar to: Debugging LowerTypeTests in LLVM Using GDB

Hi, I have made some changes in the LowerTypeTests Pass of opt, and would like to use these changes with the clang version I have downloaded. I compiled clang and llvm from scratch, made my changes in LowerTypeTests.cpp, and recompiled clang and opt. When I run clang with the appropriate flags to invoke the pass, it invokes the pass as originally written, but when I run opt on the relevant

Hello, I am adding to an LLVM pass that requires a filename as input. I am able to input this filename as a command line argument when I invoke this pass using opt, but I ultimately need to pass this argument to my code when I compile code with clang. How can I pass this argument to clang so that I can use it in my LLVM pass? Thanks for your help! Best, Shishir Jessu -------------- next part

I agree that the ArrayRef is likely the issue. I've debugged a crash caused by a temporary ArrayRef like that a couple times. Either do what David suggested or use a normal array: Metadata *mdArray[] = {ConstantInt::get(Int64Ty, 0), newMD}; ~Craig On Thu, Apr 30, 2020 at 9:56 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Apr 30, 2020 at

Hello, I am editing the LowerTypeTests pass in LLVM, and part of my additions include the following 3 lines of code: // newTypeName is a std::string MDString* newMD = MDString::get(M.getContext(), newTypeName); ArrayRef<Metadata*> mdArray {ConstantInt::get(Int64Ty, 0), newMD}; auto* node = MDTuple::get(M.getContext(), mdArray); Thus far, I have been developing on a version of Clang with

Hi, this is a proposal for the implementation of CFI-icall [1] with ThinLTO. Jumptables are generated in the merged module. To generate a jumptable, we need a list of functions with !type annotations, including (in non-cross-dso mode) external functions. Unfortunately, LLVM IR does not preserve unused function declarations, and we don’t want to copy the actual function bodies to the merged

On Mon, May 15, 2017 at 6:44 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Thanks for sending this out. A few comments below. > > On Mon, May 15, 2017 at 5:17 PM, Evgenii Stepanov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> this is a proposal for the implementation of CFI-icall [1] with ThinLTO. >> >>

Hi, I have tried to build libjpeg-turbo <https://github.com/libjpeg-turbo/libjpeg-turbo> with LTO in LLVM, using both clangbut get many errors in lld that look like the following: ld: error: undefined symbol: jpeg_std_error >>> referenced by jcstest.c:76 >>> lto.tmp:(main) ld: error: undefined symbol: jpeg_CreateCompress >>> referenced by

Hi David, Sure! Here's a function in sqlite3 called verifyDbFile, compiled with -O3. This is what it looks like when the intermediate bitcode is emitted by clang: link <https://pastebin.com/L3PrK1ac> And here's what happens after I run opt -O3 (no additional command-line arguments) on the file containing this function: link <https://pastebin.com/rZHBm2iU>. I'm not 100%

On Tue, May 23, 2017 at 4:39 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com > wrote: > On Tue, May 16, 2017 at 4:33 PM, Evgenii Stepanov > <eugeni.stepanov at gmail.com> wrote: > > On Mon, May 15, 2017 at 6:44 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> Thanks for sending this out. A few comments below. > >> > >> On

Hi David, By "dead" do you mean unreachable? My understanding was that the removal of dead code is simply another optimization, which should be disabled after adding "optnone" (and adding the function to llvm.used so the function doesn't later get deleted entirely). I am instrumenting certain basic blocks in an LLVM pass, and would like to compile a binary which

Adding a couple of lld folks. I helped Shishir debug this, the link line looked like: /home/sjessu/build/bin/clang -O0 -flto -o jcstest jcstest.o ./.libs/libjpeg.a and the issue was that libjpeg.a was created with the system ar instead of llvm-ar. It worked when recreating libjpeg.a with llvm-ar. I noticed that the lld code has some special handling for the case when there is a missing

Hello, I am adding function calls to an LLVM link-time optimization (LTO) pass, using the IRBuilder::CreateCall method. I want these calls to remain in the final x86 binary at any optimization level, but on levels -O2 and -O3, some of these calls are being optimized out. So far, I've tried adding each function in the program (excluding LLVM intrinsics) to the llvm.used set, and I've also

Hello, I am compiling a program with debugging information, and am attempting to extract !dbg numbers from function calls in LLVM IR. However, I've found a few inconsistencies. For example, this call exists in my module: %1 = tail call i1 @llvm.type.test(i8* bitcast (i32 (i32)* @_Z5otheri to i8*), metadata !"_ZTSFiiE") #5, *!dbg !69*, !nosanitize !2 I would like to extract the 69

> We could probably tolerate a certain amount of unused jump table entries. However, I just realized that all non-inline imported calls end up going through a jump table entry. Is that correct? In fact it is all calls that go through a function pointer type that is used anywhere in the program for an indirect call, but depending on your program that could be very close to "yes".

It’s not the functions themselves, it’s the jump tables that end up in the same section of the thin-link temporary object. If I have, say, foo and bar and both of them need a jump table entry, both entries will be in the same section of the temp object. The real functions will be renamed to foo.cfi and bar.cfi. If I list “foo.cfi, foo, bar.cfi, bar” in the link order file, the linker (I use lld)

Replacing direct calls to jump table entries with calls to real targets recovers most of the performance loss in my benchmark. Dealing with link order files is a bit cumbersome though: I can’t keep both, say “foo” and “foo.cfi” next to each other in link order, because if both exist, the linker reorders the jump table next to the real function. This is not what we want when the goal is to get rid

That seems to do the trick. I get “symbol ordering file: no such symbol: <blah>” warnings for symbols that didn’t get renamed. Maybe we'll have a separate order file for CFI builds... What about the comment above that line? > On May 1, 2018, at 11:46 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Tue, May 1, 2018 at 11:29 AM, <dmitry.mikulin at

Jump table sections already have this prefix: ".text..L.cfi.jumptable.”, without forcing the name with setSection(). Is that good enough? > On May 1, 2018, at 1:16 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > I think we just need to change the section name for non-MachO object formats because "__TEXT,__text,regular,pure_instructions" is the default text

Hello, I am encountering a linking failure when using Control Flow Integrity while building a shared library. It looks like the wrong relocation type is being emitted for functions referenced via the PLT. I am using clang 3.9. The error message I get is: /usr/bin/ld.gold: error: /tmp/lto-llvm-df723d.o: requires dynamic R_X86_64_PC32 reloc against 'free' which may overflow at runtime;

> On Apr 30, 2018, at 6:04 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 30, 2018 at 1:05 PM, <dmitry.mikulin at sony.com> wrote: > Replacing direct calls to jump table entries with calls to real targets recovers most of the performance loss in my benchmark. Dealing with link order files is a bit cumbersome though: I can’t keep both, say “foo” and