search for: targetsubtargetinfo

Looks like the bug here is that the InlineAsm parser and the ARM code emitter point to two different TargetSubtargetInfo instances. The attached patch corrects the issue, but is incomplete. For starters, how can I remove that const_cast? Also, the patch does not restore the TargetSubtargetInfo to its original state. So if you changed from Thumb to ARM mode, but not back to Thumb, the code emitter will generate br...

> I just tried the above code in a .s file and it worked fine for me. > Can you show exactly what you’re seeing that looks wrong? Thanks Jim. I can only reproduce the issue when that code is inline assembly in a bitcode file. Attached is a bitcode file and Makefile to demonstrate. Calling 'make' will dump two object files 'c.o' and 'asm.o'. The former is created

...main ones for Mips are endian, architecture, default CPU, and default ABI. > The goal of the configuration level of the TargetMachine is that it controls things that don't change at the object level. > This is a fairly recently stated goal, but I think it makes sense for LLVM in general. TargetSubtargetInfo takes care of > everything that resides under this (as much as possible, some bits are still in transition, e.g. TargetOptions). This is part > of my suggestion to Daniel about the problems with MCSubtargetInfo and the assembler. Targets like Mips and ARM > were unfortunately designed to c...

...t; Sent: 22 November 2013 00:56 > To: 'Jim Grosbach'; 'Evan Cheng' > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] switching ARM modes and integrated-as > > Looks like the bug here is that the InlineAsm parser and the ARM code > emitter point to two different TargetSubtargetInfo instances. The attached > patch corrects the issue, but is incomplete. For starters, how can I remove > that const_cast? Also, the patch does not restore the TargetSubtargetInfo > to its original state. So if you changed from Thumb to ARM mode, but not > back to Thumb, the code emit...

...plumbing. After that, targets without per-function ABI selection (which aside from MIPS16 includes MIPS for the foreseeable future) can just consult the TargetTuple since it's already reachable from everything. Targets that need per-function ABI selection can use the TargetTuple to initialize a TargetSubtargetInfo, override it as desired, and have the MC layer consult the TargetSubtargetInfo. >> I skipped the Triple -> TargetTuple resolution a moment ago and I should >> address that now. We already know that mapping Triple to TargetTuple is a >> many to many mapping. One Triple has many...

...in the IR. > > Yes. > The Tuple is for the sole use of front-ends, middle-ends and back-ends > to communicate and understand the *same* meaning regarding the *same* > input. > > Definitely don't want this in the middle end at all. That all can be part of the TargetMachine/TargetSubtargetInfo interface. > Having a Tuple class that encodes details of the targets go a long way > to ensure that, since you can directly pass the Tuple when you build > the Target objects, and the information it provides will be identical, > no matter where it is. Right now, we have multiple repr...

..., and see if the new light has helped understand the patch for what it will be. Maybe it's still not good enough, so then we'll have to resort to a new round of design discussions. > Definitely don't want this in the middle end at all. That all can be part of > the TargetMachine/TargetSubtargetInfo interface. Ah, yes! But the TargetMachine (& pals) are created from information from the Triple and the other bits that front-ends keep for themselves. So, in theory, if the Tuple is universal, creating them with a Tuple (instead of a Triple+stuff) will free the front-ends of keeping the rest...

----- Original Message ----- > > > > hi, > I have few question about breaking anti-dependence of postRAScheduler > in LLVM. > when I use command line "clang -target arm -mcpu=cortex-a8 -O2 > -integrated-as -c test.c -o test.o" > and get objdump file as follows: > ldr r1, [r0,#16]----(1 > str r1, [r0,#32]----(2 > ldr r1, [r0,#12]----(3 > str r1,

...ad and done this. With the attached patch applied, nothing in lib/Target/* or include/llvm/Target/* include anything from include/llvm/CodeGen. The .cpp files that moved are TargetELFWriterInfo, TargetFrameLowering, TargetLoweringObjectFile, TargetMachine, TargetOptions, TargetRegisterInfo and TargetSubtargetInfo. The .h files that moved are the matching headers for the .cpp files plus TargetInstrInfo, TargetSelectionDAGInfo and TargetLowering. Please review! More generally, I suggest reviewing the idea of moving everything rather than looking at the patch itself. The patch is lots of changing Target/X...

...solve the issue of getting the complete > > set of ABI information to every part of LLVM that needs it and you are saying > > TargetMachine should encapsulate that data directly. > Essentially. To be more precise I'm saying that TargetMachine (or an MC level equivalent > - see TargetSubtargetInfo/MCSubtargetInfo) should encapsulate everything that's needed > from the object level down for any particular target. That sounds like TargetTuple but spelt something like MCTargetMachine. It sounds like MCTargetMachine should usurp the Triple in the places it exists in the MC layer (and may...

On 16 September 2015 at 21:56, Jim Grosbach <grosbach at apple.com> wrote: > Why do we care about GAS? We have an assembler. It's not that simple. There are a lot of old code out there, including the Linux kernel which we do care a lot, that only compiles with GAS. We're slowly moving the legacy code up to modern standards, and specifically some kernel folks are happy to move up

...done this. With the attached patch applied, nothing in lib/Target/* or include/llvm/Target/* include anything from include/llvm/CodeGen. > > The .cpp files that moved are TargetELFWriterInfo, TargetFrameLowering, TargetLoweringObjectFile, TargetMachine, TargetOptions, TargetRegisterInfo and TargetSubtargetInfo. The .h files that moved are the matching headers for the .cpp files plus TargetInstrInfo, TargetSelectionDAGInfo and TargetLowering. > > Please review! More generally, I suggest reviewing the idea of moving everything rather than looking at the patch itself. The patch is lots of changing Ta...

...at is, it should be treated as a fixed property of the hardware throughout the execution of the program being compiled. This is different from, for example, floating point rounding mode, which can be changed at run-time. In LLVM, the mode would be determined by subtarget features (reflected in TargetSubtargetInfo). 2. Move the register/spill size and alignment information from MCRegisterClass, and into TargetRegisterInfo. This means that this data will no longer be available to the MC layer. Note that the size/alignment information will be provided by the TargetRegisterInfo object, and not by each indi...

...Machine as far as I can tell. What examples are you having problems with? > The goal of the configuration level of the TargetMachine is that it controls things that don't change at the object level. > This is a fairly recently stated goal, but I think it makes sense for LLVM in general. TargetSubtargetInfo takes care of > everything that resides under this (as much as possible, some bits are still in transition, e.g. TargetOptions). This is part > of my suggestion to Daniel about the problems with MCSubtargetInfo and the assembler. Targets like Mips and ARM > were unfortunately designed to c...

hi, I have few question about breaking anti-dependence of postRAScheduler in LLVM. when I use command line "clang -target arm -mcpu=cortex-a8 -O2 -integrated-as -c test.c -o test.o" and get objdump file as follows: ldrr1, [r0,#16]----(1 str r1, [r0,#32]----(2 ldr r1, [r0,#12]----(3 str r1, [r0,#36]----(4 ldr r1, [r0,#08]----(5 str r1, [r0,#40]----(6 However, I expect that instruction

...Machine as far as I can tell. What examples are you having problems with? > The goal of the configuration level of the TargetMachine is that it controls things that don't change at the object level. > This is a fairly recently stated goal, but I think it makes sense for LLVM in general. TargetSubtargetInfo takes care of > everything that resides under this (as much as possible, some bits are still in transition, e.g. TargetOptions). This is part > of my suggestion to Daniel about the problems with MCSubtargetInfo and the assembler. Targets like Mips and ARM > were unfortunately designed to c...

We've had a circular dependency in LLVM for a while, and while we've been fortunate that we could ignore it by implementing functions in header files, a recent innocent change caused a cyclic dependency between Target and CodeGen just because of inlining that happens in GCC. I'm proposing to fix this by moving code from Target to CodeGen If I understand correctly, lib/CodeGen is

...etInfo to it through the <target>AsmBackend construction. For the integrated assembler this works well because what is really passed is a derived class of <target>Subtarget. I can add stuff to MipsSubtarget without affecting any other target. Here is the inheritance: SubtargetInfo TargetSubtargetInfo <target>GenSubtargetInfo <target>Subtarget <target>Subtarget is created through TargetMachine and is codegen centric. For the standalone assembler and the clang this isn't the case. A straight SubtargetInfo object is created. >From here I added a single data member...

...Machine as far as I can tell. What examples are you having problems with? > The goal of the configuration level of the TargetMachine is that it controls things that don't change at the object level. > This is a fairly recently stated goal, but I think it makes sense for LLVM in general. TargetSubtargetInfo takes care of > everything that resides under this (as much as possible, some bits are still in transition, e.g. TargetOptions). This is part > of my suggestion to Daniel about the problems with MCSubtargetInfo and the assembler. Targets like Mips and ARM > were unfortunately designed to c...

The flag -enable-aa-sched-mi should do what you want you want in the MachineScheduler pass. If you want to do it in the selection DAG, there is a subtarget hook that might do it: TargetSubtargetInfo::useAA() LLVM won’t generate the schedule you want anyway for Intel core processors, but the alias analysis can be useful in general. -Andy On Dec 16, 2013, at 6:03 AM, Haishan <hndxvon at 163.com> wrote: > At 2013-12-15 22:43:34,"Caldarale, Charles R" <Chuck.Caldarale at...