search for: armisellow

...0x00007fff901a45c9 start + 1 18 libdyld.dylib 0x0000000000000053 start + 1877326475 Stack dump: 0. Program arguments: /sw/src/fink.build/llvm37-3.7.0-1/build/stage1/bin/clang-3.7 -cc1 -triple x86_64-apple-macosx10.10.0 -emit-obj -disable-free -main-file-name ARMISelLowering.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 242.2 -dwarf-column-info -coverage-file /sw/src/fink.build/llvm37-3.7.0-1/build/stage2/lib/Target/ARM/CMakeFiles/LLVMARMCodeGen.dir/ARMISelLower...

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...

On 12 November 2010 17:52, Bob Wilson <bob.wilson at apple.com> wrote: > I recommend implementing this as a target-specific DAG combine optimization.  We already have target-specific DAG nodes for the relevant NEON comparison operations (ARMISD::VCEQ, etc. -- see ARMISelLowering.h) as well as the vmov (ARMISD::VMOVIMM).  You just need to teach the DAG combiner how to fold them together.  Here's what you need to do (all of this code is in ARMISelLowering.cpp): Hi Bob, I thought so... I'll get cracked and see if I can generate some simple tests. Thank you ver...

...ato Golin wrote: > On 12 November 2010 17:52, Bob Wilson <bob.wilson at apple.com> wrote: >> I recommend implementing this as a target-specific DAG combine optimization. We already have target-specific DAG nodes for the relevant NEON comparison operations (ARMISD::VCEQ, etc. -- see ARMISelLowering.h) as well as the vmov (ARMISD::VMOVIMM). You just need to teach the DAG combiner how to fold them together. Here's what you need to do (all of this code is in ARMISelLowering.cpp): > > Hi Bob, > > I thought so... I'll get cracked and see if I can generate some simple t...

...l case in NEON lowering or make it as > part of an optimization pass? Which classes should I look first? I recommend implementing this as a target-specific DAG combine optimization. We already have target-specific DAG nodes for the relevant NEON comparison operations (ARMISD::VCEQ, etc. -- see ARMISelLowering.h) as well as the vmov (ARMISD::VMOVIMM). You just need to teach the DAG combiner how to fold them together. Here's what you need to do (all of this code is in ARMISelLowering.cpp): 0. (You don't actually need to do anything, but I'm just mentioning it FYI.) For selection DAG no...

Hi folks, me again, So, I want to implement a simple optimization in a NEON case I've seen these days, most as a matter of exercise, but it also simplifies (just a bit) the code generated. The case is simple: uint32x2_t x, res; res = vceq_u32(x, vcreate_u32(0)); This will generate the following code: ; zero d16 vmov.i32 d16, #0x0 ; load a

On Thu, Sep 1, 2011 at 3:17 PM, David Greene <dag at cray.com> wrote: > 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:...

...veral operators are not defined in .td file, why? (e.g., ISD::BR_CC, ISD::CopyToReg, ISD::AssertSext) 2. The MVT::glue value is used to ensure two nodes are scheduled together and in order. In the other word, we can’t insert any instruction of them in the scheduling, is it correct? 3. In the ARMISelLowering constructor, it sets the callback function with setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote); My question is ARM don’t support MVT::i1 registerclass, why should it determine this operation with MVT::i1 value? Can anyone tell me? Thank you very much. Best regards, Zakk ---------...

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 tailcalls in LLVM on ARM platform? Thank...

I get the following error 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,...

...it from front-end (Clang in this case). I'm doing this for ARM platform and the flag should be reachable from all these places in LLVM: - lib/Analysis/ValueTracking.cpp - lib/CodeGen/SelectionDAG/SelectionDAG.cpp - lib/IR/ConstantFold.cpp - lib/Target/ARM/ARMFastISel.cpp - lib/Target/ARM/ARMISelLowering.cpp - lib/Target/ARM/ARMInstrVFP.td (through predicates) - lib/Target/ARM/ARMRegisterInfo.td (through predicates) and in Clang: - lib/AST/ExprConstant.cpp Did I get it right and there is no such flag so far? Does what I'm suggesting sounds reasonable? Thanks, Sergey

...mechanism to generate switch table in a data section rather than having it interleaved with the code. This is controlled by command line flags and off by default. Also, tried to document and improve the code where I modified it. Robert -------------- next part -------------- Index: lib/Target/ARM/ARMISelLowering.h =================================================================== --- lib/Target/ARM/ARMISelLowering.h (revision 72728) +++ lib/Target/ARM/ARMISelLowering.h (working copy) @@ -147,9 +147,10 @@ /// make the right decision when generating code for different targets. const ARMSubtar...

...; 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 ask what's the st...

...> I don't have a target in front of me to run these tests at the moment, > but walking manually through va-arg-1.c, it's pretty clear that > there's some disconnect between the register spilling that happens in > LowerFORMAL_ARGUMENTS and what happens in LowerVASTART in > ARMISelLowering.cpp. > > deep > > On Thu, Jun 11, 2009 at 8:45 AM, robert muth<robert at muth.org> wrote: > > I wrote a few scripts to run llvm/arm against the gnu c torture test > suite > > which consists of over 900 smallish tests. > > > > There were quite a few...

On 29 March 2017 at 02:33, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > sin/cos are libm functions, and so a libcall to those need to honour the > floating point ABI requests. The calling convention to be followed there > should match `-mfloat-abi` (that is, -mfloat-abi=hard => AAPCS/VFP, > -mfloat-abi=soft => AAPCS). Exactly, but they're not, and that's

...te: > >> On 12 November 2010 17:52, Bob Wilson <bob.wilson at apple.com> wrote: >>> I recommend implementing this as a target-specific DAG combine optimization. We already have target-specific DAG nodes for the relevant NEON comparison operations (ARMISD::VCEQ, etc. -- see ARMISelLowering.h) as well as the vmov (ARMISD::VMOVIMM). You just need to teach the DAG combiner how to fold them together. Here's what you need to do (all of this code is in ARMISelLowering.cpp): >> >> Hi Bob, >> >> I thought so... I'll get cracked and see if I can genera...

...s it as you indicate with the writeback register listed as an output as well as an input and marked as a tied operand constraint. Search for _PRE and _POST in ARMInstrInfo.td for examples. For most instances, instruction selection is done via custom lowering, not an ISel pattern on the pattern; see ARMISelLowering.cpp for that. -Jim On Feb 7, 2011, at 8:42 AM, Jonas Paulsson wrote: > Hi, > > I would like to know how I should define these types of instructions in LLVM. > > I have for instance a load instruction that increments the address-register. I do not know how I should mark thi...

I have been struggling with this for way too long now, so hopefully the mighty list can help: I am trying to generate a byte store instruction storing the constant value 4 at some given address in a new helper function inside ARMISelLowering.cpp I tried: SDValue Val = DAG.getConstant(4, MVT::i8); SDValue Store = DAG.getStore(chain, dl, Val, Addr, MachinePointerInfo(),...

Hi, Looking at bugzilla PR11087, I'd like to conditionalise a transformation in ARMIselLowering.cpp based on whether we're compiling for codesize or performance. -Os doesn't actually exist for llc, and I can't see an obvious place where that condition would be set. Where do we specify if we're optimizing for codesize or performance? Cheers, James -------------...

On Mon, Oct 17, 2011 at 7:58 AM, James Molloy <james.molloy at arm.com> wrote: > Hi, > > > > Looking at bugzilla PR11087, I’d like to conditionalise a transformation in > ARMIselLowering.cpp based on whether we’re compiling for codesize or > performance. > > > > -Os doesn’t actually exist for llc, and I can’t see an obvious place where > that condition would be set. Where do we specify if we’re optimizing for > codesize or performance? You can key off off...