search for: llvmbb

Hi, llvmbb's job is to inform people of build breaks. However, it seems to trigger for a big list of bots, and at least one of them seems to always be broken, and the broken bots tend to have cycle times of several hours. So if you're on IRC and you commit something, you get pinged by llvmbb for hours...

...1.1/root/usr I tried adding ${CMAKE_CXX_FLAGS} to the compiler invocation in clang_compile (with and without quotes), but in both cases the resulting command is not correct, all of CMAKE_CXX_FLAGS is treated as a single option, for example: [6/67] Generating gtest-all.cc.x86_64.o FAILED: cd /home/llvmbb/clang/build-cmake-r+a/projects/compiler-rt/lib/tsan/tests/unit && /home/llvmbb/clang/build-cmake-r+a/./bin/clang -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fvisibility=hidden -fno-function-sections -O3 -gline-tables-only -Wno-gnu -Wno-varia...

On Tue, Sep 1, 2020 at 3:32 PM David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Sep 1, 2020 at 12:07 PM Nico Weber via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi, >> >> llvmbb's job is to inform people of build breaks. However, it seems to >> trigger for a big list of bots, and at least one of them seems to always be >> broken, >> > > If a bot is always broken it shouldn't be sending email/notifications - > generally they are configured...

...te: > >> On Tue, Sep 1, 2020 at 3:32 PM David Blaikie <dblaikie at gmail.com> wrote: >> >>> On Tue, Sep 1, 2020 at 12:07 PM Nico Weber via cfe-dev < >>> cfe-dev at lists.llvm.org> wrote: >>> >>>> Hi, >>>> >>>> llvmbb's job is to inform people of build breaks. However, it seems to >>>> trigger for a big list of bots, and at least one of them seems to always be >>>> broken, >>>> >>> >>> If a bot is always broken it shouldn't be sending email/notificati...

...tion, for example: >> > > Yes, recently I discovered the same problem and also though of adding > CMAKE_CXX_FLAGS > to manual clang invocations. I think it just needs to be done. > > >> >> [6/67] Generating gtest-all.cc.x86_64.o >> FAILED: cd >> /home/llvmbb/clang/build-cmake-r+a/projects/compiler-rt/lib/tsan/tests/unit >> && /home/llvmbb/clang/build-cmake-r+a/./bin/clang -fPIC -fno-builtin >> -fno-exceptions -fomit-frame-pointer -funwind-tables >> -fno-stack-protector -fvisibility=hidden -fno-function-sections -O3 >> -g...

...on about inserting instructions into the LLVM IR. I can insert instructions, but my operands do not have the right type, so it fails an assertion at runtime. I am trying to insert an immediate load instructions, as a means of claiming a new register. Here is what I do: Builder.SetInsertPoint(LLVMBB, I); // The following line looks to me like it would have a chance of loading either // address 5, or else immediate value 5. Unfortunately, it does neither. It compiles // but crashes at runtime, that the type of the operand is incompatible Instruction *newI=Builder.CreateLoad(5,"&qu...

Thank you for your answer. But there is still a problem. You seem correct about how to define a constant operand. So I added it into my code, like so: Builder.SetInsertPoint(LLVMBB, I); Constant *C = ConstantInt::get(APInt(32, 5, false)); Instruction *newI=Builder.CreateLoad(C,""); It compiles. But it still aborts at runtime with a complaint that the type is not right. This leads me to think that immediate loads are not generated with the CreateLoad...

...he LLVM IR. I can > insert instructions, but my operands do not have the right type, so it fails > an assertion at runtime. > > I am trying to insert an immediate load instructions, as a means of > claiming a new register. > > Here is what I do: > Builder.SetInsertPoint(LLVMBB, I); > > // The following line looks to me like it would have a chance o! f loading > either > // address 5, or else immediate value 5. Unfortunately, it does neither. It > compiles > // but crashes at runtime, that the type of the operand is incompatible > Instruction...

...o support efficient and quality code generation for standard register-based microprocessors.", so i want to insert my special DAG building code to the code generator. should i completely replace SelectionDAGISel, or modify SelectionDAGISel when necessary like this: LowerArguments(BasicBlock *LLVMBB) { // code for traditional target ........... for (Function::arg_iterator I = F.arg_begin(), E = F.arg_end(); I != E; ++I, ++Idx) { if (TLI.isStrangeTarget()) { //code for my strange target TLI.HandleArgment(...); continue; } //...

...in llvm::SelectionDAG::Legalize (this=0x16088a0, TypesNeedLegalizing=false, Fast=false) at LegalizeDAG.cpp:8648 #13 0x005ec313 in llvm::SelectionDAGISel::CodeGenAndEmitDAG (this=0x1608780) at SelectionDAGISel.cpp:626 #14 0x005ee7e2 in llvm::SelectionDAGISel::SelectBasicBlock (this=0x1608780, LLVMBB=0x1603fa0, Begin={<bidirectional_iterator<llvm::Instruction,int>> = {<std::iterator<std::bid\ irectional_iterator_tag ,llvm::Instruction,int,llvm::Instruction*,llvm::Instruction&>> = {<No data fields>}, <No data fields>}, NodePtr = 0x1604dd0}, End={&...

...Target/X86/X86ISelDAGToDAG.cpp:483 #13 0x007f80cc in llvm::SelectionDAGISel::CodeGenAndEmitDAG (this=0x42025600, DAG=@0xbfffe47c) at /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:4623 #14 0x0080bd86 in llvm::SelectionDAGISel::SelectBasicBlock (this=0x42025600, LLVMBB=0x41a22080, MF=@0x41a203b0, FuncInfo=@0xbfffe718) at /Volumes/Gir/devel/llvm/llvm.src/lib/CodeGen/ SelectionDAG/SelectionDAGISel.cpp:4641 #15 0x0080d35b in llvm::SelectionDAGISel::runOnFunction (this=0x42025600, Fn=@0x41a1dc40) at /Volumes/Gir/devel/llvm/llvm.src/ lib/CodeGen/SelectionDAG/Sel...

...egalize (this=0x16088a0, > TypesNeedLegalizing=false, Fast=false) at LegalizeDAG.cpp:8648 > #13 0x005ec313 in llvm::SelectionDAGISel::CodeGenAndEmitDAG > (this=0x1608780) at SelectionDAGISel.cpp:626 > #14 0x005ee7e2 in llvm::SelectionDAGISel::SelectBasicBlock > (this=0x1608780, LLVMBB=0x1603fa0, > Begin={<bidirectional_iterator<llvm::Instruction,int>> = > {<std::iterator<std::bid\ > irectional_iterator_tag > ,llvm::Instruction,int,llvm::Instruction*,llvm::Instruction&>> = > {<No data fields>}, <No data fields>}, NodeP...

...0x16088a0, >> TypesNeedLegalizing=false, Fast=false) at LegalizeDAG.cpp:8648 >> #13 0x005ec313 in llvm::SelectionDAGISel::CodeGenAndEmitDAG >> (this=0x1608780) at SelectionDAGISel.cpp:626 >> #14 0x005ee7e2 in llvm::SelectionDAGISel::SelectBasicBlock >> (this=0x1608780, LLVMBB=0x1603fa0, >> Begin={<bidirectional_iterator<llvm::Instruction,int>> = >> {<std::iterator<std::bid\ >> irectional_iterator_tag,llvm::Instruction,int,llvm::Instruction*,llvm::Instruction&>> >> = {<No data fields>}, <No data fields>}, No...

...DAG::Legalize (this=0x16088a0, > TypesNeedLegalizing=false, Fast=false) at LegalizeDAG.cpp:8648 > #13 0x005ec313 in llvm::SelectionDAGISel::CodeGenAndEmitDAG > (this=0x1608780) at SelectionDAGISel.cpp:626 > #14 0x005ee7e2 in llvm::SelectionDAGISel::SelectBasicBlock (this=0x1608780, > LLVMBB=0x1603fa0, Begin={<bidirectional_iterator<llvm::Instruction,int>> = > {<std::iterator<std::bid\ > irectional_iterator_tag,llvm::Instruction,int,llvm::Instruction*,llvm::Instruction&>> > = {<No data fields>}, <No data fields>}, NodePtr = 0x1604dd0}, &...

On 9/4/2012 11:16 AM, Khaled Mohammed wrote: > > Is there an option to do sret demotion via a register? if yes, do we > have a Target to see an example implementation? Hi Khaled, Check out X86TargetLowering::LowerReturn, and the call to getSRetReturnReg. The SRetReturnReg looks like a hack (each target that uses it, declares this variable individually), but that seems to be the

Hi, it seems like SelectionDAGBuilder expects returning of vectors (structures/arrays) to be lowered in either of the two ways: 1. Flatten the complex data types to simple data types, and return them using registers (done by TargetLowering::LowerCallTo) 2. sret demotion: return the address of the complex data type via a stack pointer Is there an option to do sret demotion via a register? if yes,

...about vector parameters? define internal fastcc <4 x float> @add(<4 x float> %a.val, <4 x float> %b.val) nounwind { entry: %tmp4 = fadd <4 x float> %a.val, %b.val ret <4 x float> %tmp4 } a and b are flattened by SelectionDAGISel::LowerArguments(const BasicBlock *LLVMBB) before letting the target handle it. SDValue NewRoot = TLI.LowerFormalArguments(DAG.getRoot(), F.getCallingConv(), F.isVarArg(), Ins, dl, DAG, InVals); The "Ins" have all the parameters flattene...

...8a0, >> TypesNeedLegalizing=false, Fast=false) at LegalizeDAG.cpp:8648 >> #13 0x005ec313 in llvm::SelectionDAGISel::CodeGenAndEmitDAG >> (this=0x1608780) at SelectionDAGISel.cpp:626 >> #14 0x005ee7e2 in llvm::SelectionDAGISel::SelectBasicBlock >> (this=0x1608780, LLVMBB=0x1603fa0, >> Begin={<bidirectional_iterator<llvm::Instruction,int>> = >> {<std::iterator<std::bid\ >> irectional_iterator_tag >> ,llvm::Instruction,int,llvm::Instruction*,llvm::Instruction&>> = >> {<No data fields>}, <No dat...

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

Duncan: I'm still stymied how this whole thread ended up about shuffle vector nodes, when the original problem was my build vector patch. I'm still working on backing the build vector patch out (it isn't clean with all of the intervening commits and I have pressing management tasks which command my attention.) -scooter On Tue, Feb 24, 2009 at 12:28 AM, Duncan Sands <baldrick at