> > As I understand it your proposal aims to help 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 maybe be introduced to a few new portions of it) and accurately reflect the desired target just like in the later stages of the TargetTuple plan intended. The main difference I see is small a small subset of the fields can be removed because they aren't needed in the MC layer and we may end up with more than one TargetTuple-like object (one for each major aspect of LLVM). I'm wondering if this point has been one big communication failure.> > My perspective on ‘the trouble with triples’: > > Given you have a GNU background I’ll pose a scenario in GCC config parlance and perhaps you > > can explain how, if at all, you see LLVM responding to the issue. This is a fake scenario but is still > > representative of what happens in the real world. > <snip> > Right now this isn't completely possible. I agree that it should be and I personally imagine this as being done via toolchain > configuring to set defaults at the clang level. We already do some of this for target, I just see it adding more to that sort > of configuration (whether or not done via autoconf is completely orthogonal of course :)The question I want to ask here is: What about API users? Things like JIT's and debuggers will want the same defaults (possibly augmented by auto-detection). One nice thing about handling this in the Triple/TargetTuple boundary was that these users get the same behaviour as clang in all areas of LLVM.> b) The lack of a TargetMachine at the MC level was something I brought up a long time ago in > this thread with my proposed solutions. This is what needs to be fixed, especially given that targets > can switch ISA, ABI, floating point, etc within a single assemble action.This is somewhat off-topic but just for my own knowledge. When you say 'ABI' here do you mean the register names or the wider ABI? I'm aware we can change register names but I don't think we can change the actual ABI on the fly. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150923/e4a2f7ad/attachment.html>
On Wed, Sep 23, 2015 at 3:26 PM Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:> > > As I understand it your proposal aims to help 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 maybe be introduced to a few new portions of it) and > accurately reflect the desired target just like in the later stages of the > TargetTuple plan intended. The main difference I see is small a small > subset of the fields can be removed because they aren't needed in the MC > layer and we may end up with more than one TargetTuple-like object (one for > each major aspect of LLVM). >Right. So I agree with some of this and not with others. a) Right now we have an is-a relationship between TargetSubtargetInfo and MCSubtargetInfo as I mentioned in an earlier mail. I really really don't like it, but changing it out is complicated. I think it'll be interesting to see how this goes with MCTargetMachine. b) I don't necessarily think it should usurp the Triple in the MC layer, but rather perform as an extra layer between MCSubtargetInfo and the rest of the assembler interface. c) I think we'll only want one MCTargetMachine for any invocation of clang/llvm-mc/etc. It should be able to mode switch (via MCSubtargetInfos possibly?) when necessary (e.g. .set mips3) similar to how TargetMachine does at the IR level.> > I'm wondering if this point has been one big communication failure. > >I think so? :)> > > > My perspective on ‘the trouble with triples’: > > > > Given you have a GNU background I’ll pose a scenario in GCC config > parlance and perhaps you > > > > can explain how, if at all, you see LLVM responding to the issue. > This is a fake scenario but is still > > > > representative of what happens in the real world. > > > <snip> > > Right now this isn't completely possible. I agree that it should be and > I personally imagine this as being done via toolchain > > configuring to set defaults at the clang level. We already do some of > this for target, I just see it adding more to that sort > > of configuration (whether or not done via autoconf is completely > orthogonal of course :) > > The question I want to ask here is: What about API users? Things like > JIT's and debuggers will want the same defaults (possibly augmented by > auto-detection). One nice thing about handling this in the > Triple/TargetTuple boundary was that these users get the same behaviour as > clang in all areas of LLVM. >JIT users already have to construct the TargetMachine. As do debugger users. A JIT user should be configuring as they'd like to execute things without (possibly) taking into account what the surrounding binary is doing (as you can have interprocess jitting anyhow). A debugger should, theoretically at least, be using the ELF flags of the target binary. If something can't be represented there we'll generally use a section of flags if I recall what we did with gcc when we needed to pass extraneous data around.> > > b) The lack of a TargetMachine at the MC level was something I brought > up a long time ago in > > this thread with my proposed solutions. This is what needs to be fixed, > especially given that targets > > can switch ISA, ABI, floating point, etc within a single assemble action. > > This is somewhat off-topic but just for my own knowledge. When you say > 'ABI' here do you mean the register names or the wider ABI? I'm aware we > can change register names but I don't think we can change the actual ABI on > the fly. >Wider ABI, i.e. something like .set fpmath= could change the ABI for surrounding functions. I'm... disappointed at how that works in the ELF flags case, but it might be less of an issue. -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150923/eb0f5102/attachment.html>
> > > The question I want to ask here is: What about API users? Things > > > like JIT's and debuggers will want the same defaults (possibly > > > augmented by auto-detection). One nice thing about handling > > > this in the Triple/TargetTuple boundary was that these users > > > get the same behaviour as clang in all areas of LLVM. > > > > Only the compiler driver is impacted by customised meanings of > > triples. It is a JIT’s responsibility to know what it is targeting > > and if that needs to match the host compiler then that information > > needs to be extracted from the pre-processor breadcrumbs available > > when compiling the JIT driver itself which describe the options the > > JIT driver is being built with; these then have to be translated into > > TargetMachine settings. A JIT won’t know what triple to use let alone > > the other data without taking it from its own build environment.There's llvm::sys::getDefaultTargetTriple() but taking it from its own configure script or similar makes sense.> > For disassemblers a similar story applies the information needs to be taken > > from the ELF though this time and anything missing is a failing of the > > MIPS ELF format which would need extending to carry the information. > > .MIPS.abiflags helps massively here though.I've realized the bit I'm missing on the debugger side. When there is no ELF, it's the target and/or users responsibility to tell the debugger what it is.> JIT users already have to construct the TargetMachine. As do debugger > users. ...That's right. The TargetMachine is constructed from a Triple (and other arguments). The thing I'm trying to clarify is which CPU is selected for the following calls: createTargetMachine("mips-linux-gnu", "", "", ...) createTargetMachine("mips-linux-gnu", "generic", "", ...) createTargetMachine("mips-linux-gnu", "native", "", ...) At the moment, all three will select mips32 but I believe "native" and "generic" should have a platform dependent minimum (i.e. MIPS-II on Debian, MIPS32R2 on Fedora) in the same way a clang's default will be platform dependent.> > b) The lack of a TargetMachine at the MC level was something I brought up a long time ago in > > this thread with my proposed solutions. This is what needs to be fixed, especially given that targets > > can switch ISA, ABI, floating point, etc within a single assemble action. > > This is somewhat off-topic but just for my own knowledge. When you say 'ABI' here do you mean > the register names or the wider ABI? I'm aware we can change register names but I don't think > we can change the actual ABI on the fly. > > Wider ABI, i.e. something like .set fpmath= could change the ABI for surrounding functions. I'm... disappointed at how that works in the ELF flags case, but it might be less of an issue. > > -eric(The closest I could find to '.set fpmath=' is '.set fp=' so I guess you mean that.) Switching between FP32/FP64/etc. makes sense to me. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150924/eb692ecb/attachment.html>