search for: armcc

...0, r1 moveq r2, #1 To implement this, I first emit a compare instruction and then I'm trying to emit the conditional move, which is failing. BuildMI(&MBB, DL, TII->get(ARM::CMPrr)) .addReg(MI.getOperand(1).getReg()) .addReg(MI.getOperand(2).getReg()) .addImm(ARMCC::EQ); BuildMI(MBB, MBBI, MI.getDebugLoc(), TII->get(ARM::MOVr), MI.getOperand(0).getReg()) .addImm(ARMCC::EQ) .addImm(1) .addReg(0); // 's' bit But with the last conditional move, I am a bit lost. The result of the condional move should...

...ing them in llvm-gcc and clang is for compatibility for ARM's specifications and with ARM's RVCT compiler.  If ARM does not care about those things, I'd love to remove the struct wrappers from llvm. As Al said earlier, you definitely don't need the structures for compatibility with armcc. As far as the LLVM back-end is concerned, with or without structures, the instruction selection works a treat and generates correct NEON instructions. If the final object has the correct instructions and follows ARM ABIs, there is no point in keeping IR compatibility. I also noticed that Clang...

...m-gcc and clang is for compatibility for ARM's specifications and with ARM's RVCT compiler. If ARM does not care about those things, I'd love to remove the struct wrappers from llvm. > > As Al said earlier, you definitely don't need the structures for > compatibility with armcc. An implementation, such as in GCC, that does not use structures is compatible with ARM's specification in only one direction. GCC will accept any code written for RVCT, but not the other way around. And, as Al pointed out, there are also compatibility issues with how you can initialize vect...

...an initialize vectors.  (In fact, if you stick to the documented interfaces, the only way you can initialize a vector to an arbitrary value is by loading from memory.) Hi Bob, Can you clarify what compatibility problems you had with GCC? And that by using structures in Clang you made it work with armcc? Is it just a source code compatibility issue? > Can we get an official position from ARM on this? I really don't know what you want here. I can't tell you that it will be safe to remove the structures from Clang, since I don't know enough about the vector types (and all other b...

..." to "ADDS"( provided we somehow determine that we need ADDS here), then everything else related to ARM instruction generation has been handled in current infrastructure. Is this correct or do we need to modify other things also? 2. In file ARMISelLowering.cpp, inside function FPCCtoARMCC, condition ISD::SETO generates ARMCC::VC ( Overflow clear) condition. Thus, if we are able to appropriately generate ISD::SETO inside SDNode for overflow clear and then map it to ARMCC::VC instruction in IntCCtoARMCC, then will that be enough to generate the an instruction like "addvc"?...

...ht fix is to add a pass to optimize away the cmp instruction by *folding* it in the preceding add when it's legal. Ideally this will be a target independent pass that x86 and other targets can take advantage of as well. > > > 2. In file ARMISelLowering.cpp, inside function FPCCtoARMCC, > condition ISD::SETO generates ARMCC::VC ( Overflow clear) condition. > Thus, if we are able to appropriately generate ISD::SETO inside > SDNode for overflow clear and then map it to ARMCC::VC instruction > in IntCCtoARMCC, then will that be enough to generate the an > in...

...39;t know all the decisions taken > on NEON specs or why GCC had the design decisions it had. But I can't > possibly believe that they have to do what ARM says they should. Can we ask Lee or Richard or somebody for a ruling on why the spec is the way it is? It would probably also help if armcc's arm_neon.h were available publicly for us to examine to further the discussion. What's being debated here seems like an optimization for compile time. I'm certainly in favor of that, but I can think of a ton of things I'd rather that we work on first that matter for correctness....

...the beginning of the tree while LLVM only does when needed (metadata-style). The relocation sections in GCC are huge and they also use debug_loc in many more cases than LLVM, for instance extern functions, global variables and the cases I mentioned in my example before. Of course, Dwarf produced by Armcc is also different (though, closer to what GCC does, for obvious reasons). One way we could do this, slowly and painfully, but surely, is to generate Dwarf, use the debugger to make sure that Dwarf actually produces what GDB is expecting (you probably have many cases already) and take a snapshot of...

...1) above seems to say exactly that. You're taking conclusions on your own thoughts... please don't put words in my mouth. The only point I made in my first email is that using structures in the IR was not necessary, regardless of the headers. If you want to keep source compatibility with armcc, I welcome and can help you. -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm

On Mar 17, 2011, at 8:44 AM, Renato Golin wrote: >> dwarfdump --verify will do this. > > Is this being used in LLVM tests? This is an idea. It is not used in llvm/test tests. > I had a look at your debug tests in clang and they're similar to what I do here. > > The problem with debug tests is that it doesn't depend only on the > compiler, but on the debugger

Support for NEON intrinsics in clang is not complete. Poly types in general are known to be an issue, and the vceq_p8 in your example definitely needs an intrinisic. It should work with llvm-gcc. Can you clarify ARM's position on those structure types? It sounds like you are advocating that we get rid of them. The only reason we've been using them in llvm-gcc and clang is for

Hi, We currently have a downstream patch (attached) which implements some new addressing modes that enable position-independent code for small embedded systems. Is this something that would be accepted upstream? I think the ARM backend changes are fairly uncontroversial, but the clang changes introduce a lot of ROPI/RWPI specific changes in otherwise target-independent code. If the clang changes

...ite code for GCC's implementation. GCC lets you freely > intermix vector types, or at least integer vector types, as long as > they have the same total size. Yes, other problem cases might be int16x4_t x = { 1, 2, 3, 4 }; // gcc only? struct float4: float32x4_t { ... }; // armcc only? We ought to be more specific about the portable subset, and give more guidance on potential portability issues. Probably that would start with a common specification for the NEON intrinsics, independent of any given ARM or GNU compiler release. Al -- IMPORTANT NOTICE: The contents of this...

...In fact, if you stick to the documented interfaces, the only way you can initialize a vector to an arbitrary value is by loading from memory.) > > Hi Bob, > > Can you clarify what compatibility problems you had with GCC? And that > by using structures in Clang you made it work with armcc? > > Is it just a source code compatibility issue? Yes, there are multiple issues but they all involve source compatibility. Here is an example: #include <arm_neon.h> uint32x2_t test(int32x2_t x) { return vadd_u32(x, x); } This works fine with GCC because int32x2_t and uint32x2_t ar...

On Jul 14, 2008, at 12:59 PM, kapil anand wrote: > Hi all, > > I am using LLVM compiler and CodeGen for generating ARM binaries. > > I was going through the code for ARM backend. I noticed that the ARM > Condition field( Bits 31-28) is generated by converting the > conditions used in icmp and branch. For example, if I have following > C Code > > int a,b,c,d;

...e llvm integrated assembler could > support this feature as well. > Hi David, As much as I think that it's important to add support for old codebases to be compiled, I also have to consider the importance of compatibility and compiler sanity. Adding support for this GNU extension (that ARMCC also seem to support) can: 1. Add multiple representations to the same operation, which is fine when you're converting ASM into binary, but not so much when you're doing the reverse. We have been trying to deprecate pre-UAL and GNU-extensions as much as possible, and this is a move that i...

...thread on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110086.html With your help and the information about the condition codes I was able to resolve the error:         BuildMI(BB, BB.end(), DL, TII->get(ARM::tCMPi8)).addReg(ARM::R0).addImm(1).add(predOps(ARMCC::AL); But how do I know how many and which condition codes each instruction needs? [MOVi takes 3 operands relating to the condition code (all after the immediate)] There is no info about that in the ARMInstrThumb.td file. -Julius On 03/23/2018 12:18 AM, Tom Stellard wrote: > On 03/22/2018 0...

> > > > - Dead code elimination (ADCE, BDCE) > > > Regarding BDCE: The trivialized values might indeed be irrelevant to > later calculations, but might harm the debugging experience? If BDCE > only was applied at O2 and higher, that's likely not a huge loss. > Regular DCE (meaning without the bit-tracking parts) is probably fine > for O1. > > >

On 27 September 2010 18:19, Bob Wilson <bob.wilson at apple.com> wrote: > I'm not sure what you mean by this.  The llvm intrinsics and built-in vector operations use plain vectors regardless of the front-end.  The structures are only relevant for things like argument passing and copying -- you can't do anything else with them.  Can you post an example of the 5X IR code size that

Hi all, I am using LLVM compiler and CodeGen for generating ARM binaries. I was going through the code for ARM backend. I noticed that the ARM Condition field( Bits 31-28) is generated by converting the conditions used in icmp and branch. For example, if I have following C Code int a,b,c,d; c = a+b; if(c==0) d = a + 10; Then I get ( Assembly Instructions with opcodes only) add *cmp*