search for: arminstrinfo

...r, GPR:$val), NoItinerary, [(set GPR:$dst, (atomic_load_min_32 GPR:$ptr, GPR:$val))]>; both reference atomic_load_min_32, and the latter should instead reference atomic_load_umin_32 Added here, See http://llvm.org/viewvc/llvm-project/llvm/tags/RELEASE_30/final/lib/Target/ARM/ARMInstrInfo.td?diff_format=h&view=diff&r1=130233&r2=130234 Still present in trunk http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td?diff_format=h&view=annotate Cheers, George

...[(set GPR:$dst, (atomic_load_min_32 GPR:$ptr, GPR:$val))]>; > > both reference atomic_load_min_32, and the latter should instead > reference atomic_load_umin_32 > > Added here, > See > http://llvm.org/viewvc/llvm-project/llvm/tags/RELEASE_30/final/lib/Target/ARM/ARMInstrInfo.td?diff_format=h&view=diff&r1=130233&r2=130234 > > Still present in trunk > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td?diff_format=h&view=annotate > > Cheers, > George > _______________________________________________ > LL...

...(atomic_load_min_32 GPR:$ptr, GPR:$val))]>; >> >> both reference atomic_load_min_32, and the latter should instead >> reference atomic_load_umin_32 >> >> Added here, >> See >> http://llvm.org/viewvc/llvm-project/llvm/tags/RELEASE_30/final/lib/Target/ARM/ARMInstrInfo.td?diff_format=h&view=diff&r1=130233&r2=130234 >> >> Still present in trunk >> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td?diff_format=h&view=annotate >> >> Cheers, >> George >> _____________________________...

Hi Everyone, I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, and had some questions. Currently, it defines quite a few methods like printAddrMode4Operand (linked to ARMInstrInfo.td) that currently assume raw text support in the OutStreamer. Are these methods still supposed to be invoked in the MC'ized path for assembly output? Is JimG's new MC/.s ARMAsmPrinter::EmitInstruction() somehow bypassing these completely? and also on EmitStartOfAsmFile(), it emits a bunc...

On Sep 29, 2010, at 3:09 PM, Jason Kim wrote: > Hi Everyone, > > I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, > and had some questions. > > Currently, it defines quite a few methods like printAddrMode4Operand > (linked to ARMInstrInfo.td) that currently assume raw text support in > the OutStreamer. Are these methods still supposed to be invoked in the > MC'ized path for assembly output? > Is JimG's new MC/.s ARMAsmPrinter::EmitInstruction() somehow bypassing > these completely? > The ones in ARMAsmPrinte...

Hi Jim, > Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not obvious to me why. Attributes should be emitted into object file as well... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Sep 29, 2010, at 3:58 PM, Anton Korobeynikov wrote: > Hi Jim, > >> Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not obvious to me why. > Attributes should be emitted into object file as well... Yes, but surely not by a function explicitly indicated to be for assembly files. I would expect there to be an

On Sep 29, 2010, at 4:27 PM, Jason Kim wrote: >> Yes, but surely not by a function explicitly indicated to be for assembly files. I would expect there to be an equivalent function to do what needs done for object files. Perhaps there isn't one (yet) and that's what's leading to the confusion? > > LOL :-) Yes, maybe that's it. Included is a patch w comments that >

On Wed, Sep 29, 2010 at 4:00 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Sep 29, 2010, at 3:58 PM, Anton Korobeynikov wrote: > >> Hi Jim, >> >>> Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not obvious to me why. >> Attributes should be emitted into object file as well... > >

...ent. We’ve checked out the poolalloc/safecoode projects and there’s some helpful analysis tools, but didn’t find anything relevant to ID lowering. Our current thrust is to define a custom target intrinsic function (@llvm.arm.cfiid) that we can insert into the IR and lower using a definition in the ARMInstrInfo.td file. Right now, I’m trying to define the pattern and instruction in that file. At first, I just inserted a pattern to lower our intrinsic into a “trap” instruction, which worked fine: /* Code in IR/IntrinsicsARM.td */ /* Note, I’m not positive that IntrNoReturn is correct here, but IntrNoMem...

Hi Mikaël, Thanks for the patch. Some comments: 1. Please don't use tabs. 2. Index: lib/Target/ARM/ARMInstrInfo.cpp =================================================================== --- lib/Target/ARM/ARMInstrInfo.cpp (revision 14) +++ lib/Target/ARM/ARMInstrInfo.cpp (working copy) @@ -904,7 +904,8 @@ return TAI->getInlineAsmLength(MI- >getOperand(0).getSymbolName()); if (MI-&...

...get->is64Bit()) > ^ > > > Even if no errors after comment `if (Subtarget->is64Bit())` in > RISCVInstrInfo.td, but it is monkey patch, and it can't handle riscv64 > without the if condition check. > > And I noticed there is `if (Subtarget->useMovt(*MF))` in ARMInstrInfo.td too > https://github.com/llvm-mirror/llvm/blob/master/lib/Target/ARM/ARMInstrInfo.td#L694 I haven't looked into this, but I would imagine that none of the patterns using that are supported yet, and that's why we don't see any errors for ARM yet. > How ARM handle this? and I r...

Hi all, FlexyCore, the company I am working for, use LLVM to generate binary for ARM platform. We are very fulfilled with LLVM, and FlexyCore will be pleased to contribute on this software. We need debug support in ARM binary, but, in LLVM 2.4, this support is not activated for ARM backend. Consequently, I made small modifications in order to activate it (see the patch in attach file). My

...ists can be extended either with a "+=" operator in a let statement or placing a '"+" in front of a superclass: - Example 1: def D0 : C1 { let Predicates += [P2]; // Append P2 to C1's Predicates } - Example 2: def D0 : C1, +AddP1; Using a real example, MOVi16 (in ARMInstrInfo.td) which is defined as def MOVi16 : AI1<0b1000, (outs GPR:$Rd), (ins imm0_65535_expr:$imm), DPFrm, IIC_iMOVi, "movw", "\t$Rd, $imm", [(set GPR:$Rd, imm0_65535:$imm)]>, Requires<[IsARM, HasV6T2]>, U...

...er rs to register rd and places the result in rd; add.cc rd, rs does the same and updates the condition codes. Can anybody point out an example of how such instructions should be defined in a corresponding xxInstrInfo.td file please? ARM has similar instruction pairs, look at ADD/ADDS, SUB/SUBS in ARMInstrInfo.td /jakob

Hi Jonas, There's not really a very clean way to do this currently. The ARM backend does 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 instruc...

...we start differentiating between > cortex-a8 and cortex-a15 for code generation. Probably most relevant is the combination of features given to each processor in lib/Target/ARM/ARM.td. This vmul/vmla difference comes from "FeatureHasSlowFPVMLx", via ARMSubtarget.h's useFPVMLx and ARMInstrInfo.td's UseFPVMLx. Cheers. Tim.

Hi All, I started to work on code-size improvements on ARM target by comparing GCC and LLVM generated code. My first candidate was switch-case lowering. I also created a Bugzilla issue for this topic: https://bugs.llvm.org/show_bug.cgi?id=34902 The full example code and the generated assembly for GCC and for LLVM is in the Bugzilla issue. My first idea was to simplify the following

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 this - should the address register as well be in the outs list, or should some other flag be set, perhaps? Thank you, /Jonas -------------- next part -------------- An HTML attachment was

Hello, I'm just starting to work on a backend for a custom cpu. For some instructions this cpu has two flavors: first performs an operation, and the second performs an operation and updates condition codes (carry, zero, overflow, negative etc) based on the outcome. For example: add rd,rs instruction adds the contents of register rs to register rd and places the result in rd; add.cc rd, rs