similar to: llc tool followed by g++ : Abnormal behavior while compiling assembly to object file

Hi Mahesh, On 23 April 2018 at 10:51, Mahesh Attarde via llvm-dev <llvm-dev at lists.llvm.org> wrote: > movq .str at GOTPCREL(%rip),%rdi > movq .str.1 at GOTPCREL(%rip),%rsi That's quite strange. You wouldn't normally expect to access a constant string via the GOT. It looks like LLVM has decided to put the symbols in an odd section, so it'd be a good idea to make sure

That works. Thanks. One more followup question though. Once i run opt on bitcode, there is not useful output/transform on bitcode. this rpt files are extra. I am hoping to do something like this, ; RUN: FileCheck --input-file=a.rpt.gold --check-prefix=CHECK-A < a.rpt ; RUN: FileCheck --input-file=b.rpt.gold --check-prefix=CHECK-B < b.rpt i did not find much examples in tests hence

Hello I have pass operating on bitcode file which produces more than one equivalent representation. opt --my-pass <%s | Filecheck %s --my-pass generates files a.rpt b.rpt c.rpt . How do i write test without writing all 3 files to stdin. I have considered CHECK-LABEL for each. it creates bulky checks. Thanks Mahesh -------------- next part -------------- An HTML attachment was

Hi Hongbin I am not quite familiar with AnalysisUsage, let me correct question a bit. I have read Writing Pass <http://llvm.org/docs/WritingAnLLVMPass.html#specifying-interactions-between-passes>, All examples that i see here are based on collecting information .i.e Analysis Passes. I wonder if this applies to Transformation passes also. e.g. void MyInliner::getAnalysisUsage(AnalysisUsage

Hello I am working on pass which has dependency on multiple passes. Say D1,D2,D3 I used INITIALIZE_PASS_BEGIN INITIALIZE_PASS_DEPENDENCY(D1) INITIALIZE_PASS_DEPENDENCY(D2) INITIALIZE_PASS_DEPENDENCY(D3) INITIALIZE_PASS_END. While running it through opt tool it, I had to specify this D1,D2,D3 pass names to get this pass executed before my pass. Is there way, to let llvm pass manager to know

Oops. My bad. I mean to write match-file being my match pattern. and a.rpt being file generated by opt. ;RUN: FileCheck <match-file>a.rpt.gold --input-file=a.rpt. mahesh On Sat, Mar 31, 2018 at 6:57 PM, Mahesh Attarde <coder.mahesh at gmail.com> wrote: > That works. Thanks. > > One more followup question though. > Once i run opt on bitcode, there is not useful

Hi Mahesh, On 31 March 2018 at 11:45, Mahesh Attarde via llvm-dev <llvm-dev at lists.llvm.org> wrote: > opt --my-pass <%s | Filecheck %s > > --my-pass generates files a.rpt b.rpt c.rpt . How do i write test without > writing all 3 files to stdin. You can run FileCheck over them on separate RUN lines assuming you know the filename (which I assume you do since you'd be

On targets that fully support MC for encoding (today that means X86, hopefully ARM will be done soon), llc has a "-show-mc-encoding" option that can be used to dump out the encodings for every instruction. If you're using clang, this can be accessed with the (intentionally) hidden -mllvm option like so: $ clang t.c -S -o - -mllvm -show-mc-encoding -mkernel -O3 -fomit-frame-pointer

See: http://llvm.org/docs/CommandGuide/FileCheck.html It is not required to pipe output to FileCheck; there is the --input-file option, which allows you to run FileCheck on an existing disk file. Something like this: FileCheck %s --input-file a.rpt --check-prefix=A FileCheck %s --input-file b.rpt --check-prefix=B FileCheck %s --input-file c.rpt --check-prefix=C If there are common parts to each

Hi I have IR Code like ... @path = private constant [6xi8] c"abcde\00" ... --- Code from Pass --- GlobalVariable * GVPath = .... // contains @path I want to convert "abcde" to StringRef. Can you help me with GlobalVariable API? GlobalVariable::getInitializer() --> Constant* // How to get exact value äbcde from here? ~mahesh -------------- next part --------------

On Tue, Oct 25, 2016 at 1:48 PM, Rafael Espíndola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > So, for the declaration, do you expect to know the value? If not just > a declaration to a GlobalVariable should be sufficient. > No, the value will be discovered at link time, but we want instruction selection to treat the symbol as an immediate, not a GlobalAddress that will

Hi Jay - I see the slow, small accesses using an older clang [Apple LLVM version 7.0.0 (clang-700.1.76)], but this looks fixed on trunk. I made a change that comes into play if you don't specify a particular CPU: http://llvm.org/viewvc/llvm-project?view=revision&revision=245950 $ ./clang -O1 -mavx copy.c -S -o - ... movslq %edi, %rax movq _spr_dynamic at GOTPCREL(%rip),

On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rostedt at goodmis.org> wrote: > On Wed, 4 Oct 2017 14:19:56 -0700 > Thomas Garnier <thgarnie at google.com> wrote: > >> When using -fPIE/PIC with function tracing, the compiler generates a >> call through the GOT (call *__fentry__ at GOTPCREL). This instruction >> takes 6 bytes instead of 5 on the usual

On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rostedt at goodmis.org> wrote: > On Wed, 4 Oct 2017 14:19:56 -0700 > Thomas Garnier <thgarnie at google.com> wrote: > >> When using -fPIE/PIC with function tracing, the compiler generates a >> call through the GOT (call *__fentry__ at GOTPCREL). This instruction >> takes 6 bytes instead of 5 on the usual

On Dec 14, 2010, at 9:37 PM, Chris Lattner wrote: > On targets that fully support MC for encoding (today that means X86, hopefully ARM will be done soon), llc has a "-show-mc-encoding" option that can be used to dump out the encodings for every instruction. If you're using clang, this can be accessed with the (intentionally) hidden -mllvm option like so: > > $ clang t.c

Dear Mr. Northover, Thank you for the quick reply. You are correct about the address-mode operands :) . I guess an important detail left out was that the basic block (call it A) that wants to calculate the address of the target stationary trampoline basic block (call it B) will be moved around in memory during run-time. Our earlier solution, before the feature was implemented to move around (A)

Hi LLVM developers, As PR35281 mentioned: $ llvm-objcopy -O binary llvm-cortex-m7.elf llvm-cortex-m7.bin llvm-objcopy: 'llvm-cortex-m7.elf': The file was not recognized as a valid object file. if (ELFObjectFile<ELF64LE> *o = dyn_cast<ELFObjectFile<ELF64LE>>(&Binary)) https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-objcopy/llvm-objcopy.cpp#L200

I encountered a segfault when using lld to cross-compile for Windows (+MinGW) from Linux. The problem happens with objects built by gcc. The problem is that ObjFile::CreateRegular considers a PendingComdat to be valid (and later causes an illegal pointer dereference). The following patch fixes the crash: diff --git a/COFF/InputFiles.cpp b/COFF/InputFiles.cpp index 9e2345b0a..f47d612df 100644

If you call lld::coff::link twice, the second time gives this backtrace: msvcp140d.dll!00007ffc35830806() Unknown > zig.exe!std::_Debug_pointer<lld::coff::Chunk * __ptr64 const>(lld::coff::Chunk * const * _Ptr, const wchar_t * _File, unsigned int _Line) Line 926 C++ zig.exe!std::_Debug_range2<lld::coff::Chunk * __ptr64 const * __ptr64>(lld::coff::Chunk * const *

+Rui and Peter On Wed, Jul 25, 2018 at 8:34 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Here's a fix: > > --- a/lld/COFF/Driver.cpp > +++ b/lld/COFF/Driver.cpp > @@ -72,6 +72,9 @@ bool link(ArrayRef<const char *> Args, bool CanExitEarly, > raw_ostream &Diag) { > exitLld(errorCount() ? 1 : 0); > > freeArena(); > +