[LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo
Renato Golin
renato.golin at linaro.org
Tue May 26 10:43:17 PDT 2015
On 26 May 2015 at 14:58, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> The intention isn't to change the kind of triples/tuples in use by toolchains and users. There's a lot of legacy and inertia to overcome if we try that. The intention is to map the ambiguous/insufficient GNU triples onto an internal representation as early as possible and pass that internal representation throughout LLVM and the LLVM-IR files. The end-users can still use GNU triples and compiler options such as -EL/-EB, -m32/-m64, etc. and these will be reflected in the internal LLVM tuple.
Ok, so that will probably involve the Triple / Parser refactoring I'm doing.
Right now, Triple handles some of that, but it's not authoritative not
final. I've created an ARMTargetParser class that deals with parsing
arch/cpu/fpu strings, and I'm moving all string parsing in Clang (LLVM
is done already) to it. We may also have to move llc, lli and others.
Once this is done, we can begin to move more logic to the Triple in
the same way, and let target specific Triple management in their own
classes (like ARMTargetParser), so that Clang doesn't need all
back-ends to have all arch knowledge. This way, the Triple class will
be able to take any architecture-specific decision with just strings.
Such arch-specific classes will, later, be built from a special
table-gen back-end that will always be enabled for all targets, but
that's much later.
The final goal is to keep all that information into one big
TargetDescription class, which will also help Clang and other users to
know information about the targets, for instance, what combination of
environment, ABI and CPU features, to take informed decisions without
needing any back-end built in.
Is that in line with your reasoning?
cheers,
--renato
More information about the llvm-dev
mailing list