search for: subtargetinfo

Eli, Yes, SubtargetInfo is more of a container of convenience since it is available to all the assemblers. Working with the current framework it seemed the least disruptive. I'll describe the problem again. The Mips ABI for better or worse, uses the ELF headers e_flags extensively. The most pressing issue is the n...

On Fri, Dec 14, 2012 at 1:03 PM, Carter, Jack <jcarter at mips.com> wrote: > Eli, > > This is the kind of feedback I want. I believe I have to add to the base class so it should be generally useful. I can see string being better for the value. I still am enamoured with an enumeration for the tab though: int->string. How would that be a limitation? > I guess that's fine,

On Fri, 2015-02-20 at 13:47 -0500, Rafael Espíndola wrote: > > Your task, should you choose to accept it, is to make it cope with other > > forms of relaxation where necessary. > > And if not, please open a bug :-) http://llvm.org/bugs/show_bug.cgi?id=22662 FWIW I could reproduce the 'movl foo, %ebx' one but a relative jump *was* using 16 bits (although gas uses 8):

Hi, while implementing SystemZTTI:getCacheSize(), it became clear that there really isn't a simple way to just ask the Subtarget for the current subtarget machine model. I was thinking like something of an enum that would also reflect the subtarget series (and would allow >= and similar operations). I would like to ask what the ideas are on how this should be done best. Some

...a mismatch either. I think that part of this is the same problem that is observed in PR36542 the ARMAsmBackend that is responsible for widening the tail call to a Thumb2 branch is created with ARMv4T which doesn't support Thumb1. There has been a recent change that threads through the existing SubtargetInfo instead of recreating it from the triple alone. It is worth mentioning that the object level BuildAttributes do not include Thumbv7a which is misleading to a linker as it will be expecting no ARMv7A in the object. Has there already been a discussion about what per function code-generation with Bui...

...I think that part of this is the same problem that is observed in > PR36542 the ARMAsmBackend that is responsible for widening the tail > call to a Thumb2 branch is created with ARMv4T which doesn't support > Thumb1. There has been a recent change that threads through the > existing SubtargetInfo instead of recreating it from the triple alone. > It is worth mentioning that the object level BuildAttributes do not > include Thumbv7a which is misleading to a linker as it will be > expecting no ARMv7A in the object. > > Has there already been a discussion about what per function...

...CodeModel(CodeModel), OptLevel), Subtarget(TT, Cpu, FeatureString, *this, Options, getCodeModel(), OptLevel), TLOF(new LanaiTargetObjectFile()) { initAsmInfo(); } Note that Subtarget is created as part of constructor. On the other hard, initAsmInfo() tries to create a subtargetinfo as well. The "Subtarget" created here later on is returned through: const LanaiSubtarget * getSubtargetImpl(const llvm::Function & /*Fn*/) const override { return &Subtarget; } ARM/X86 does differently. ARMBaseTargetMachine::ARMBaseTargetMachine(const Target &T, con...

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

...the delay slot filling logic ( from Sparc and Mips ) into single target independent pass. These is just a primary investigation. I am not expert with all architectures supposed by LLVM but MIPS, x86 and to some extent ARM. I have question regarding Target hooks. Does it means using TargetInfo an SubTargetInfo class and at runtime decide architecture type and based on that perform optimization ( i.e use target specific instructions ) ? Please help me ! Am I going in right direction ? Suggest some code , document to look for further ideas. Also if any one like to mentor me for this project. Sincerely, V...

...[Input welcome!]. * Do any out-of-tree backends have custom calling convention code that requires more information than original arg type and whether the argument is fixed or not? In the RISC-V calling convention implementation I'd be happiest if the calling convention function had access to SubtargetInfo and the DataLayout, but can probably do without. Does anyone have views on this, or insight into planned future developments of calling convention handling in GlobalISel? Thanks, Alex

...should also use CGContext. It should be possible to override those modes with command line options, but I don't think we should have ad-hoc overrides buried within passes. I think it would be cleanest if the IR pass pipeline had an explicit point at which the subtarget gets initialized--say a SubtargetInfo pass. IR passes that run early can still get architecture defaults from TargetTransformInfo, but can't make any subtarget specific queries. IR passes that run after this point should be able to make CGContext queries, either directly or via TargetTransformInfo (I'm not sure there is any rea...

...ll as the standalone one. But the 2 gather information that ends up in the ELF header in different ways such as assembler directives in the standalone assembler such as ".options pic0" which forces non-shared relocation model. The direction I am going in is to add a new data member in MCSubtargetInfo that is a std::set. This set of booleans are target specific and is used as a bulletin board. This allows me to update my MipsSubtargetInfo object whenever it or a derived reference of it is available. I have a reference of SubtargetInfo in <target>ELFObjectWriter in my current patch. I am...

...s]>, assuming I've added a new predicate 'IsMClass'), but getting the generated decoder to be subtarget-dependent was quite an invasive change. I also had to do the same with the MCInstPrinter - it can't know whether to print mask names for the M-series or the AR-series without a SubtargetInfo. I'd like to know if yourself or perhaps Owen/Eric has any input on the track I'm going down. From my (possibly tunnel-visioned) perspective it's the only logical solution, and I'm surprised that having the parser/printer operate without subtarget specific knowledge hasn't caus...

...he LLVMContext? This would also allow them to be cached in the same way, and it would make them available to any part of the middle or backend that wanted them. > > I think it would be cleanest if the IR pass pipeline had an explicit point > at which the subtarget gets initialized--say a SubtargetInfo pass. IR > passes that run early can still get architecture defaults from > TargetTransformInfo, but can't make any subtarget specific queries. IR > passes that run after this point should be able to make CGContext queries, > either directly or via TargetTransformInfo (I'm not s...

...t; * Do any out-of-tree backends have custom calling convention code that > requires more information than original arg type and whether the argument is > fixed or not? In the RISC-V calling convention implementation I'd be happiest > if the calling convention function had access to SubtargetInfo and the > DataLayout, but can probably do without. > > Does anyone have views on this, or insight into planned future developments of > calling convention handling in GlobalISel? > > Thanks, > > Alex -- Regards, Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/

On Fri, Dec 15, 2017 at 5:30 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Are there reasons why we might not want to do this? Other options we should > consider? It does make the TargetMachine -> TargetIRAnalysis path less abstract, but given that all targets have the same pattern of instantiating a TargetIRAnalysis with a Function->TargetTransformInfo hook, the abstraction does

...; I've added a new predicate 'IsMClass'), but getting the generated decoder to be > subtarget-dependent was quite an invasive change. I also had to do the same with > the MCInstPrinter - it can't know whether to print mask names for the M-series > or the AR-series without a SubtargetInfo. > > I'd like to know if yourself or perhaps Owen/Eric has any input on the track I'm > going down. From my (possibly tunnel-visioned) perspective it's the only logical > solution, and I'm surprised that having the parser/printer operate without > subtarget specific...

...standalone one. But the 2 gather information that ends up in the ELF header in different ways such as assembler directives in the standalone assembler such as ".options pic0" which forces non-shared relocation model. > > The direction I am going in is to add a new data member in MCSubtargetInfo that is a std::set. This set of booleans are target specific and is used as a bulletin board. This allows me to update my MipsSubtargetInfo object whenever it or a derived reference of it is available. I have a reference of SubtargetInfo in <target>ELFObjectWriter in my current patch. I don...

...ons: vldN instructions can load up to 4 128-bit vectors, but they can still only be used as 128-bit vectors. If other targets possess similar, then they could well benefit; if not, then it's probably pointless. > I have question regarding Target hooks. Does it means using TargetInfo an > SubTargetInfo class and at runtime decide architecture type and based on > that perform optimization ( i.e use target specific instructions ) ? I think they more normally live in TargetTransformInfo. > Please help me ! Am I going in right direction ? Suggest some code , > document to look for further...

On 3/15/2018 9:43 AM, Peter Smith via llvm-dev wrote: > Hello everyone, this is most likely Arm specific, but could affect > other targets where there is a somewhat complex relationship between > the triple and mcpu option. > > At present when clang is used as a linker driver for the gold-plugin > and when using and an explicit -mcpu is not given to clang, then clang > will