search for: mctargetmachin

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

Hi all, Thank you so much for this discussion. It has been very helpful and educational. I think that I understand the perspectives of both Tim and Renato. Let me briefly summarize them to ensure that I correctly understand: Renato’s perspective is that the triple means whatever the author says it does, and that may or not be meaningful. :) In the case of armv7l (for example) it has a clear

...is needed because it appears in a path. Whatever uses triple today would then consult individual pieces of information in the TargetMachine instead. (As before I don’t think we need dwell on this here though but instead begin discussion about enhancing TargetMachine to start with and then inventing MCTargetMachine.) Daniel Sanders Daniel.Sanders at imgtec.com<mailto:Daniel.Sanders at imgtec.com> writes: 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 t...

...not the ABI (which is currently unavailable to the relevant object). I have three patches that make a start on a general solution for this kind of problem (http://reviews.llvm.org/D13858, http://reviews.llvm.org/D13860, and http://reviews.llvm.org/D13863). The overall intent is that we create an MCTargetMachine that describes the desired target (taking into account the default ABI for the triple and any options that change it) and use it as a factory for the MC layer objects. This way we can pass relevant detail down to the MC objects without having to have all targets agree on what information should be...

I am implementing a defined, but currently unimplemented by LLVM, ABI. This ABI differs from an existing ABI in its ELF object format by implementing a subset of an existing ABI, but encoded differently and by setting the e_ident EI_CLASS field. I am trying to use MCTargetOptions::getABIName to set a boolean in the modified subclass of MCELFObjectTargetWriter to indicate which relocation encoding

Eric Christopher echristo at gmail.com<mailto:echristo at gmail.com> writes: > 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. I’ve been watching this thread in

On 19 Oct 2015, at 19:05, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I find the git imerge script extremely useful for this kind of situation. > > https://github.com/mhagger/git-imerge > > Logically, it does something similar to rebasing your local branch onto EVERY commit in the upstream branch, in turn, until it finds conflicts. There is

> > > The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will likely be incorrect. > > > > If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect. > > If it's something that's overridden later