search for: uselist

I finally got back to this. It is a known and endemic issue that pops up from time to time. The issues I’m aware of so far are related to random sets being used where strict order is required. This may result in non-deterministic uselists issued by the bitcode/assembly writers. There is no great way to go about pro-active testing for this. Collecting the tests so far and running them as regression tests occasionally might serve as a feel better bandage. Neither can I think of good checks in a verifier. These bugs show up from time...

...I should mention the reason somewhere earlier. "Reversing the order of arg0~3 is not intentional. The user list of pixel_idx happens to have pixel_idx+3, pixel_idx+2, and pixel_idx+1 in this order, so LSR simply follows this order when collecting the LSRFixups." I'm not an expert on uselist orders, but after skimming Duncan Smith's recent work on preserving uselist orders in assembly, these orders are deterministic but arbitrary. So blindly following these orders sometimes cause funny behavior (as in my example). On Mon, May 18, 2015 at 10:10 AM, Daniel Berlin <dberlin at dber...

...9;s dump). However I get a failed assertion at Module Verifier which says: --- Instruction referencing instruction not embedded in a basic block! <existing instruction> <removed instruction> --- The problem is, the existing instruction holds a reference to the removed instruction in its UseList, i.e. the removed instruction needs the result if the existing instruction (so the removal is legal). Should I go over all the UseList`s and remove the reference? Thanks, Michael.

Hello again, > It may be desirable to sort the table before writing the bitcode out, > adding Peter to the thread for his opinion. Thanks for this! Now it seems I've been optimistic about this result. I have instrumented the test suite to check it on a wider amount of files and quickly discovered that it fails for larger optimization sequences. In particular, the default -O3 set

...ace(1)* %in", and in the LLVM IR, there is a @llvm.dbg.value like: call void @llvm.dbg.value(metadata <16 x float> addrspace(1)* %in, i64 0, metadata !216, metadata !28), !dbg !217 How I can retrieve this @llvm.dbg.value when I have "%in"? Since Metadata is not a part of the uselist anymore, is there some way rather than iterate over every instructions in the function to get this @llvm.dbg.value? Thanks Hongbin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171122/878b7ba5/attachment.h...

...36 1537 case Instruction::BitCast: 1538 return selectBitCast(I); 1539 (gdb) call I->dump() %2 = call float @llvm.powi.f32(float %0, i32 %1) (gdb) (gdb) print *I $12 = {<llvm::Value> = { _vptr$Value = 0x60c67f0 <vtable for llvm::CallInst+16>, VTy = 0x61035c0, UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, SubclassID = 68 'D', HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', SubclassData = 0, NumOperands = 3, static MaximumAlignment = 536870912}, OperandList = 0x61b8e80} (gdb)

Hmmm... It seems like I should check out how the UseList on Value (and its child BasicBlock) work. On Tue, May 1, 2018 at 8:34 PM, Keith Wyss <wyssman at gmail.com> wrote: > Hi, > > I'm trying to understand how clang keeps track of which declarations are > called within a translation unit and decides to codegen their definitions....

Hi, I'm trying to understand how clang keeps track of which declarations are called within a translation unit and decides to codegen their definitions. DeclBase.h has a markUsed to keep track of ODR use, and I think that the decl can be found from the symbol table via ASTContext.h (for example looking up a template via GetQualifiedTemplateName -> getAsTemplateDecl -> setIsUsed ). This

...> 1539 > (gdb) call I->dump() > %2 = call float @llvm.powi.f32(float %0, i32 %1) > (gdb) > (gdb) print *I > $12 = {<llvm::Value> = { > _vptr$Value = 0x60c67f0 <vtable for llvm::CallInst+16>, VTy = > 0x61035c0, > UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, > SubclassID = 68 'D', > HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', > SubclassData = 0, NumOperands = 3, static MaximumAlignment = > 536870912}, > OperandList = 0x61b8...

...538 return selectBitCast(I); > 1539 > (gdb) call I->dump() > %2 = call float @llvm.powi.f32(float %0, i32 %1) > (gdb) > (gdb) print *I > $12 = {<llvm::Value> = { > _vptr$Value = 0x60c67f0 <vtable for llvm::CallInst+16>, VTy = > 0x61035c0, > UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, SubclassID = 68 > 'D', > HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', > SubclassData = 0, NumOperands = 3, static MaximumAlignment = > 536870912}, > OperandList = 0x61b8e80} > (gdb) >...

...extra overheads. ü Global variables should be cloned for several times, it is a big memory penalty. Design of function-based parallelism [cid:image001.png at 01CE824E.0C5C7950] Step 1: Make LLVM pass Reentrant l Function passes should be thread-safe since function-based parallelism is adopted. l UseList and ValueHandleList of 'Constant' class may be accessed by different functions; all operations on UseList and ValueHandleList should be locked. l LLVMContext will be shared by different functions; all accesses to LLVMContext should be locked. l For allocators which use default SlabAllocat...

...>> 1539 >> (gdb) call I->dump() >> %2 = call float @llvm.powi.f32(float %0, i32 %1) >> (gdb) >> (gdb) print *I >> $12 = {<llvm::Value> = { >> _vptr$Value = 0x60c67f0 <vtable for llvm::CallInst+16>, VTy = >> 0x61035c0, >> UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, SubclassID = 68 >> 'D', >> HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', >> SubclassData = 0, NumOperands = 3, static MaximumAlignment = >> 536870912}, >> OperandList = 0x61b8...

...e end of the pass is same as the IR after the call to remapInstructions(..) is made. 3. While executing remapInstructions(..), the uses of %ref.tmp are replaced with %0 in %tmpcast definition when From-AI->replacesAllUsesWith(Inst) call is made. This is triggering the bug. It basically grabs the UseList (one of them being the definition of %tmpcast) and renames all the %ref.tmp uses to %0. *Basic Block IR before replaceAllUsesWith method is executed*: entry: %a = alloca %struct.e, align 1 %ref.tmp = alloca { <2 x float>, <2 x float> }, align 8 %tmpcast = bitcast { <2 x float...

Here is a WIP patch as promised: http://reviews.llvm.org/D13829 It uses a hungoff uselist to store optional data as needed. Some early objections from Duncan: - An extra one-time malloc() is required to set personality functions. - We get and set personality functions frequently. This patch introduces a level of indirection which slows the common case down. Is this overhead a...

...pected behaviour? This is the output when I type "print *V1" in gdb: {_vptr.Value = 0x91fa950, SubclassID = 92 '\\', HasValueHandle = 1 '\001', HasMetadata = 0 '\000', SubclassOptionalData = 31 '\037', SubclassData = 43368, VTy = {Ty = 0x921f6fc}, UseList = 0x8d5a550, Name = 0x8e06088} This is the output when I type "print *V1->getType()" in gdb: {<llvm::AbstractTypeUser> = {_vptr.AbstractTypeUser = 0x92184c0}, ID = 72, Abstract = true, SubclassData = 299242, RefCount = 153191633, Context = @0x89f3aac, ForwardType = 0x0,...

...PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > >> On 2015-Oct-16, at 13:54, Vedant Kumar <vsk at apple.com> wrote: >> >> Here is a WIP patch as promised: >> >> http://reviews.llvm.org/D13829 >> >> It uses a hungoff uselist to store optional data as needed. >> >> Some early objections from Duncan: >> >> - An extra one-time malloc() is required to set personality functions. >> - We get and set personality functions frequently. This patch introduces a level of indirection which slows...

I'm running into some pretty bad performance in llc.exe when compiling some large neural networks into code that contains some very large llvm::ConstantDataArrays, some are { size=102,760,448 }. There's a small about of actual code for processing the network, but the assembly is mostly global data. I'm finding that llc.exe memory spikes up around 30 gigabytes and the job takes 20-30

Hi guys, Suppose I have an IR file on disk, and I access it via a Module pass. Also suppose that the bitcode file hasn't changed, and no transformation passes have run. Then can I safely assume that every time my Module pass executes code like the following, it will always visit the Module's Functions, BasicBlocks, and Instructions in the same order? for (auto const & Fn : Module)

...b/gcc/x86_64-linux-gnu/6Foundcandidate GCC installation:/usr/lib/gcc/x86_64-linux-gnu/6.3.0SelectedGCC installation:/usr/lib/gcc/x86_64-linux-gnu/6.3.0Candidatemultilib:.;@m64Selectedmultilib:.;@m64"/usr/local/bin/clang-4.0"-cc1 -triple x86_64-unknown-linux-gnu -emit-llvm-bc -emit-llvm-uselists -disable-free -main-file-name contribJIT.cpp -mrelocation-model pic -pic-level 2-mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64-v -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file /home/iku...

Oups, sorry for the mistake, llcj (not llc:)) is not more maintained! Gaël Le 10 sept. 2014 00:27, "Gaël Thomas" <gael.thomas00 at gmail.com> a écrit : > Hi Brian, > > So, I confirm, llc is not more maintained. And using vmjc is probably > the good starting point to translate Java bytecode into llvm bitcode. > > However, I think that your hack (changing the way