search for: irobjectfil

Hi Rafael, There's a source file in Chromium that does something like this: target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" module asm ".text" module asm "foo: ret" declare void @foo() define void @_start() { call void @foo() ret void } Currently the llvm-nm output for that looks like this:

...to specify the ABI. In the case of LLVMCreateDisasmCPUFeatures(), they'd move to a new variant of this function and some backward compatibility fixups would be left in the pre-existing version to maintain its current level of functionality where only the default ABI for the triple is available. IRObjectFile would need some means of determining the ABI otherwise IRObjectFile::CollectAsmUndefinedRefs() would produce a slightly different result for some assembly inputs. This is because a small number of directives introduce references on particular ABI's and not on others. I think this information w...

As part of trying to fix PR30610 (ThinLTO with module inline asm), I wanted to add an assert that we have a Target and an MCAsmParser when we have non-null module inline asm in IRObjectFile::CollectAsmUndefinedRefs. Otherwise it silently fails to parse the module inline asm, which I initially found when trying to add an 'opt' based test for my fix (because 'opt' wasn't initializing asm parsers, something I am fixing). However, I had a test case failure in test/LT...

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

On 24 June 2016 at 06:02, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > Hi, > > Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in

On 19 September 2014 15:54, Steven Wu <stevenwu at apple.com> wrote: > Yes, we don’t need to edit the assembly in the file, but we need to modified the CHECK line to reflect the output of current llvm-dis. I was talking about updating the CHECK in all the previous version. Does that make sense? Yes, the CHECK lines would have to be updated, but that seems like a pretty small annoyance.

...at ld64 has similar problems. > > > I suspect ld64 would need to be update to handle this scheme. Somehow it > need to be able to extract the object from the section. > Do you mean the bitcode object? There's already support in LLVM for this ( http://llvm-cs.pcc.me.uk/lib/Object/IRObjectFile.cpp#269). I suspect the tricky part (which I was unsuccessful at doing with gold) will be convincing the linker that the bitcode object and the regular object are two separate things. Otherwise this should work, but I suspect the applicability (leaving CFI > aside) may not concern that many fu...

...[RFC] Exhaustive bitcode compatibility tests for IR > features > > > Hi Rafael, > > I have a quick question for you. First of all I am not very familiar with this > code, so.... > > > Before this change: > > [llvm] r212349 - Implement LTOModule on top of IRObjectFile > http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/195450 > > > LTOModule::parseSymbols used to explicitly add global aliases as defined > symbols: > > // add aliases > for (const auto &Alias : IRFile->aliases()) > addDefinedDataSymbol(Alias); &gt...

...rn that ld64 has similar problems. > > I suspect ld64 would need to be update to handle this scheme. Somehow it need to be able to extract the object from the section. > > Do you mean the bitcode object? There's already support in LLVM for this (http://llvm-cs.pcc.me.uk/lib/Object/IRObjectFile.cpp#269 <http://llvm-cs.pcc.me.uk/lib/Object/IRObjectFile.cpp#269>). I suspect the tricky part (which I was unsuccessful at doing with gold) will be convincing the linker that the bitcode object and the regular object are two separate things. > > Otherwise this should work, but I susp...

Hi, Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in the triple and that's the only information MipsMCAsmInfo has. This would be fine if it N32 was

Hi Eric, It's the unsolved problems on the pass-MCTargetOptions-everywhere path that are my main concern with that approach rather than the amount of work. The first problem is that the result of IRObjectFile::CollectAsmUndefinedRefs() depends on the ABI but IRObjectFile doesn't know it. How would you deliver the ABI to IRObjectFile? The second problem is that IRLinker will link incompatible IR together because it doesn't know the ABI's involved in the link. It thinks it's sufficient to...

...similar problems. >> >> I suspect ld64 would need to be update to handle this scheme. Somehow it need to be able to extract the object from the section. >> >> Do you mean the bitcode object? There's already support in LLVM for this (http://llvm-cs.pcc.me.uk/lib/Object/IRObjectFile.cpp#269 <http://llvm-cs.pcc.me.uk/lib/Object/IRObjectFile.cpp#269>). I suspect the tricky part (which I was unsuccessful at doing with gold) will be convincing the linker that the bitcode object and the regular object are two separate things. >> >> Otherwise this should work, bu...

...sub list? Something like Func1 <-> Func2 <-> Var1 <-> Var2 <-> Alias1 <-> Alias2 <-> IFunc1 <-> Ifunc2 and keep FirstFunc, FirstVar, FirstAlias and FirstIFunc pointers. One place where having another list might be a bit annoying is the symbol iterator of IRObjectFile. Cheers, Rafael On 22 December 2015 at 08:23, Dmitry Polukhin <dmitry.polukhin at gmail.com> wrote: > I start prototyping second approach that makes ifunc new type of > GlobalValue. And I would like to reconfirm how much we would like to share > between aliases and ifuncs. For ex...

...an into problems with some users of MCAsmInfo not initializing MCTargetOptions. There is also a problem with some users of MCAsmInfo not knowing the ABI. For example, llvm-objdump doesn't know the ABI until it starts reading the object file but has to initialize the MCAsmInfo earlier than that. IRObjectFile was another problem area. From: Reid Kleckner [mailto:rnk at google.com] Sent: 22 May 2015 16:22 To: Daniel Sanders Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo I think MCAsmInfo was really inten...

...dded >> to your linker (e.g. to invoke the LLVM hooks to write the stage-2 >> combined function map and either launch the backend processes in >> parallel or write out a make or other build file). The current support >> for reading native object wrapped bitcode is baked into IRObjectFile >> so presumably the Sony linker can handle these native object wrapped >> bitcode files if it uses libLTO. We would similarly embed the handling >> of the function index/summary behind an API that can handle either so >> it is similarly transparent to the linkers. Let me k...

...ect.dir/Archive.cpp.o CMakeFiles/LLVMObject.dir/ArchiveWriter.cpp.o CMakeFiles/LLVMObject.dir/Binary.cpp.o CMakeFiles/LLVMObject.dir/COFFObjectFile.cpp.o CMakeFiles/LLVMObject.dir/ELF.cpp.o CMakeFiles/LLVMObject.dir/ELFObjectFile.cpp.o CMakeFiles/LLVMObject.dir/Error.cpp.o CMakeFiles/LLVMObject.dir/IRObjectFile.cpp.o CMakeFiles/LLVMObject.dir/MachOObjectFile.cpp.o CMakeFiles/LLVMObject.dir/MachOUniversal.cpp.o CMakeFiles/LLVMObject.dir/ModuleSummaryIndexObjectFile.cpp.o CMakeFiles/LLVMObject.dir/Object.cpp.o CMakeFiles/LLVMObject.dir/ObjectFile.cpp.o CMakeFiles/LLVMObject.dir/RecordStreamer.cpp.o CMakeFi...

...es/LLVMObject.dir/ArchiveWriter.cpp.o > CMakeFiles/LLVMObject.dir/Binary.cpp.o > CMakeFiles/LLVMObject.dir/COFFObjectFile.cpp.o > CMakeFiles/LLVMObject.dir/ELF.cpp.o > CMakeFiles/LLVMObject.dir/ELFObjectFile.cpp.o > CMakeFiles/LLVMObject.dir/Error.cpp.o > CMakeFiles/LLVMObject.dir/IRObjectFile.cpp.o > CMakeFiles/LLVMObject.dir/MachOObjectFile.cpp.o > CMakeFiles/LLVMObject.dir/MachOUniversal.cpp.o > CMakeFiles/LLVMObject.dir/ModuleSummaryIndexObjectFile.cpp.o > CMakeFiles/LLVMObject.dir/Object.cpp.o > CMakeFiles/LLVMObject.dir/ObjectFile.cpp.o > CMakeFiles/LLVMObject.di...

Hi, I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file format. For ELF32 they begin with '$' and for ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select

On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: > Jack, > > What version of CMake are you using? > > -Chris Chris, I am using cmake 3.5.2. My read of this problem is as follows. While libLLVM.dylib is being linked against -lxar when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib is created with -Wl,-dead_strip such that

...ThinLTO handling would have to be added to your linker (e.g. to invoke the LLVM hooks to write the stage-2 combined function map and either launch the backend processes in parallel or write out a make or other build file). The current support for reading native object wrapped bitcode is baked into IRObjectFile so presumably the Sony linker can handle these native object wrapped bitcode files if it uses libLTO. We would similarly embed the handling of the function index/summary behind an API that can handle either so it is similarly transparent to the linkers. Let me know if there would be additional iss...