search for: armtargetlowering

John, I've moved with patches to HEAD and unfortunately the comments about disabling tailcalls do not go away with this update. Please see ARMTargetLowering::LowerCall in lib/Target/ARM/ARMISelLowering.cpp line 1208 and later. It looks like man can use -arm-tail-calls, but one never knows how good it is since the comment tells it clearly: // Temporarily disable tail calls so things don't break. so I would like to ask what's the status of ta...

...e necessary for GHC. > > Cameron > > On Jun 17, 2011, at 1:31 PM, Karel Gardas wrote: > >> >> John, >> >> I've moved with patches to HEAD and unfortunately the comments about >> disabling tailcalls do not go away with this update. Please see >> ARMTargetLowering::LowerCall in lib/Target/ARM/ARMISelLowering.cpp line >> 1208 and later. It looks like man can use -arm-tail-calls, but one never >> knows how good it is since the comment tells it clearly: >> >> // Temporarily disable tail calls so things don't break. >> >>...

...port GuaranteedTailCallOpt, which might be necessary for GHC. Cameron On Jun 17, 2011, at 1:31 PM, Karel Gardas wrote: > > John, > > I've moved with patches to HEAD and unfortunately the comments about > disabling tailcalls do not go away with this update. Please see > ARMTargetLowering::LowerCall in lib/Target/ARM/ARMISelLowering.cpp line > 1208 and later. It looks like man can use -arm-tail-calls, but one never > knows how good it is since the comment tells it clearly: > > // Temporarily disable tail calls so things don't break. > > so I would like to a...

...gt;> >> On Jun 17, 2011, at 1:31 PM, Karel Gardas wrote: >> >>> >>> John, >>> >>> I've moved with patches to HEAD and unfortunately the comments about >>> disabling tailcalls do not go away with this update. Please see >>> ARMTargetLowering::LowerCall in lib/Target/ARM/ARMISelLowering.cpp line >>> 1208 and later. It looks like man can use -arm-tail-calls, but one never >>> knows how good it is since the comment tells it clearly: >>> >>> // Temporarily disable tail calls so things don't break. &...

+ Eli Friedman as he often has very insightful comments regarding back end changes. On Fri, Jan 4, 2019 at 9:03 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > The changes seem fine to me. I don't think this is excessively intrusive > and it accomplishes what is needed by targets whose call lowering can > introduce illegal types. > Adding Justin Bogner as the

...r pc, [r3, +r0, lsl #2 .POOL_ADDR: .text .LJTI9_0_0: .data .LJTI9_0_0: .long .LBB9_2 .long .LBB9_5 .long .LBB9_7 .long .LBB9_4 .long .LBB9_8 .text The code for the lowering lives mostly in SDValue ARMTargetLowering::LowerBR_JT with some more heavy lifting done by ARMISD::WrapperJT My attempts at this are marked in the code below. My problem is to come up with the right item/value to put into the constant pool. SDValue ARMTargetLowering::LowerBR_JT(SDValue Op, SelectionDAG &DAG) { SDValue Chain = Op.ge...

...ng frontend command failed with exit code 70 (use -v to see invocation) clang version 3.8.0 (trunk) It looks as if the newly added emitAtomicCmpXchgNoStoreLLBalance() function is the culprit. Does this seem like a resaonable fix, or do I need to do something different for v6 and earlier? void ARMTargetLowering::emitAtomicCmpXchgNoStoreLLBalance( IRBuilder<> &Builder) const { if (Subtarget->hasV7Ops()) { Module *M = Builder.GetInsertBlock()->getParent()->getParent(); Builder.CreateCall(llvm::Intrinsic::getDeclaration(M, Intrinsic::arm_clrex)); } } -Rich

Folks, I'm working on bug 16387: "clang doesn't produce ARM EABI-compliant modulo runtime function" http://llvm.org/bugs/show_bug.cgi?id=16387 And I need some pointers. I've changed ARMISelLowering::ARMTargetLowering::ARMTargetLowering() to associate __aeabi_idivmod variants to RTLIB::{U,S}DIVREM_* library calls, but now I need to teach the expansion that on AEABI case, the remainder is not on the stack, but on registers. However, SelectionDAGLegalize::ExpandDivRemLibCall() assumes the remainder is *always* on...

...y project to start learning at least Haskell and ARM. My current state of the work is attached in the form of patch against LLVM 2.9. I'm not really qualified to judge your patch, but please note that to have it accepted into LLVM you'll need to make it work on ToT. > Also in the llvm::ARMTargetLowering::LowerCall I see a comment about disabling tailcalls just to not break things. I believe this has been changed on ToT, so since Haskell is presumably completely dependent on tail calls working, you'll need to work there. > Also is there any way how to convince llc to support -debug argumen...

.../lib/libc.so.1 #4 0x08fc40fa in llvm::llvm_unreachable_internal (msg=0x0, file=0x0, line=0) at ErrorHandling.cpp:99 #5 0x08bcbf19 in llvm::CCState::AnalyzeCallOperands (this=0x8045c80, Outs=@0x8046350, Fn=0x88c7838 <ARM_AAPCS_GHC>) at CallingConvLower.cpp:126 #6 0x088cb08a in llvm::ARMTargetLowering::LowerCall (this=0x92b4c58, Chain= {Node = 0x92d1b50, ResNo = 0}, Callee={Node = 0x92d1c60, ResNo = 0}, CallConv=llvm::CallingConv::GHC, isVarArg=false, isTailCall=@0x804656b, Outs=@0x8046350, OutVals=@0x8046230, Ins=@0x8045f30, dl={LineCol = 0, ScopeIdx = 0}, DAG=@0x92bdea8,...

...r during compilation using the LLVM cross-compiler (x86_64->arm). error: nested functions are disabled, use -fnested-functions to re-enable With -fnested-functions switch, I get the following error: <llvm-src-dir>/llvm/lib/Target/ARM/ARMISelLowering.cpp:1439: virtual llvm::SDValue llvm::ARMTargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&): Assertion `0 && "Don't know how to custom lower this!"' failed. frobos/tests/hello.c:453: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://...

...MInstrInfo. > > > > Thanks, > > Prathamesh > > > > On Tue, 7 Apr 2020 at 23:55, John Brawn <John.Brawn at arm.com> wrote: > > > > > > If I'm understanding what's going on in this test correctly, what's happening is: > > > * ARMTargetLowering::LowerCall prefers indirect calls when a function is called at least 3 times in minsize > > > * In thumb 1 (without -fno-omit-frame-pointer) we have effectively only 3 callee-saved registers (r4-r6) > > > * The function has three arguments, so those three plus the register we ne...

I'm getting this build error with -Werror: [off-opt] : [llvm] cc1plus: warnings being treated as errors [off-opt] : [llvm] /ptmp/dag/llvm/official/llvm/lib/Target/ARM/ARMISelLowering.cpp: In member function 'llvm::MachineBasicBlock* llvm::ARMTargetLowering::EmitAtomicBinary64(llvm::MachineInstr*, llvm::MachineBasicBlock*, unsigned int, unsigned int, bool, bool) const': [off-opt] : [llvm] /ptmp/dag/llvm/official/llvm/lib/Target/ARM/ARMISelLowering.cpp:5336: error: 'contBB' may be used uninitialized in this function [off-opt] : [llvm]...

.../ARM/ARMISelLowering.cpp:1142! 0 llc 0x08a8cbf8 1 llc 0x08a8d124 2 0x55577400 __kernel_sigreturn + 0 3 0x55577430 __kernel_vsyscall + 16 4 libc.so.6 0x5571525f gsignal + 79 5 libc.so.6 0x557187b5 abort + 373 6 llc 0x08a7426c 7 llc 0x0821437c llvm::ARMTargetLowering::CCAssignFnForNode(llvm::CallingConv::ID, bool, bool) const + 92 8 llc 0x08219e60 llvm::ARMTargetLowering::LowerFormalArguments(llvm::SDValue, llvm::CallingConv::ID, bool, llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::DebugLoc, llvm::SelectionDAG&, llvm::SmallVectorI...

...; invocation) >> clang version 3.8.0 (trunk) >> >> It looks as if the newly added emitAtomicCmpXchgNoStoreLLBalance() >> function is the culprit. Does this seem like a resaonable fix, or do I need >> to do something different for v6 and earlier? >> >> void ARMTargetLowering::emitAtomicCmpXchgNoStoreLLBalance( >> IRBuilder<> &Builder) const { >> if (Subtarget->hasV7Ops()) { >> Module *M = Builder.GetInsertBlock()->getParent()->getParent(); >> Builder.CreateCall(llvm::Intrinsic::getDeclaration(M, >> Intrinsi...

...disabled by default in llvm-gcc (not sure why - maybe a historical hang over from the days when they were not supported?). > With -fnested-functions switch, I get the following error: > > <llvm-src-dir>/llvm/lib/Target/ARM/ARMISelLowering.cpp:1439: virtual > llvm::SDValue llvm::ARMTargetLowering::LowerOperation(llvm::SDValue, > llvm::SelectionDAG&): Assertion `0 && "Don't know how to custom lower > this!"' failed. > frobos/tests/hello.c:453: internal compiler error: Aborted > Please submit a full bug report, > with preprocessed source if appropr...

...-gcc (not sure why - > maybe a historical hang over from the days when they were not supported?). > > > With -fnested-functions switch, I get the following error: > > > > <llvm-src-dir>/llvm/lib/Target/ARM/ARMISelLowering.cpp:1439: virtual > > llvm::SDValue llvm::ARMTargetLowering::LowerOperation(llvm::SDValue, > > llvm::SelectionDAG&): Assertion `0 && "Don't know how to custom lower > > this!"' failed. > > frobos/tests/hello.c:453: internal compiler error: Aborted > > Please submit a full bug report, > > with prepr...

...> why - > maybe a historical hang over from the days when they were not > supported?). > > > With -fnested-functions switch, I get the following error: > > > > <llvm-src-dir>/llvm/lib/Target/ARM/ARMISelLowering.cpp:1439: virtual > > llvm::SDValue llvm::ARMTargetLowering::LowerOperation(llvm::SDValue, > > llvm::SelectionDAG&): Assertion `0 && "Don't know how to custom > lower > > this!"' failed. > > frobos/tests/hello.c:453: internal compiler error: Aborted > > Please submit a full bug report, > > wit...

If I'm understanding what's going on in this test correctly, what's happening is: * ARMTargetLowering::LowerCall prefers indirect calls when a function is called at least 3 times in minsize * In thumb 1 (without -fno-omit-frame-pointer) we have effectively only 3 callee-saved registers (r4-r6) * The function has three arguments, so those three plus the register we need to hold the function addres...

...derived from %3. And since r3 is a call-clobbered register, the compiler is forced to reload foo's address each time before blx. To fix this, I thought of following approaches: (a) Disable the heuristic to prefer indirect call when there are at least 3 calls to same function in basic block in ARMTargetLowering::LowerCall for Thumb-1 ISA. (b) In ARMTargetLowering::LowerCall, put another constraint like number of arguments, as a proxy for register pressure for Thumb-1, but that's bound to trip another cases. (c) Give higher priority to allocate vrit reg used for indirect calls ? However, if that resu...