[PATCH] D21779: [LTO] Infer EKind/EMachine from Bitcode files

[Daniel Sanders via llvm-commits]

> > On Thu, Jul 7, 2016 at 6:45 AM, Daniel Sanders <daniel.sanders at imgtec.com<mailto:daniel.sanders at imgtec.com>> wrote:
> > dsanders added a comment.
> > > > Ah, interesting. So N32 is a 32-bit ABI on 64-bit MIPS just like x32 ABI is on x86-64. Do you know how to determine whether it is ELF32 or ELF64 for such triple?
> > >  In some ways, yes, but N32 has full support for 64-bit arithmetic. It was created to be similar to N64 but avoid the portability problems and bloat associated with 64-bit pointers.
> > I've just noticed I've misread the table I was looking at. You're right, N32 serves the same purpose for 64-bit MIPS as X32 does for x86-64.
> Yup, x32 is not a popular ABI but it exists and different from i386 ABI. :) It made me wonder if we have the same issue for x32. Will your patch address the issue for x32 as well? (I'm just wondering because we don't support x32 in LLD yet.)

It doesn't look like X32 has the same problem. In fact, X86 seems to have solved the problem in almost the exact same way as my current patch series :-). The only difference being that it's adjusting the triple in the clang driver instead of cc1 and cc1as. The driver is probably the right place for it but I had trouble with the adjusted triple ending up in library paths when I tried it that way. I'll mention this in the other thread and hopefully that will unblock my patch series. I'll take another look at doing it in the driver while I'm waiting for people to reply.

You should be able to use 'Triple::getEnvironment() == Triple::GNUX32' to identify X32 since the current implementation computeTargetTriple() in the driver switches between Triple::GNUX32, Triple::GNU, and Triple::CODE16 to match the -m16/-m32/-mx32/-m64 options.