[cfe-dev] Incorrect assumptions in MIPS backend

[Daniel Sanders via cfe-dev]

It ought to work for your use case but unfortunately I can't fix this bug until the first few pieces of the Triple/TargetTuple work discussed in 'The Trouble with Triples' thread is in place. A lot of the Mips backend was written on the assumption that the Triple object was a reliable source of information and this has turned out to be a mistake. Once the Triple/TargetTuple work is in place the current implementation will be correct and I'll be able to properly separate CPU's from ABI's and get rid of this assertion.

If it's just a list of CPU's you're looking for then you may want to add a method to MCSubtargetInfo that extracts the list from MCSubtargetInfo::ProcDesc.

> -----Original Message-----
> From: Matthew Fernandez [mailto:matthew.fernandez at nicta.com.au]
> Sent: 21 September 2015 04:37
> To: Daniel Sanders
> Cc: cfe-dev at lists.llvm.org
> Subject: RE: [cfe-dev] Incorrect assumptions in MIPS backend
> 
> Thanks, Daniel. I guess calling llc in this way to probe the supported CPUs is
> not necessarily expected. The repeated help text seems to suggest this as
> well. I'll revert to probing support by calling Clang with my target CPU and
> checking the error code. Thanks for your explanation.
> 
> On 18 September 2015 01:55:52 GMT+10:00, Daniel Sanders
> <Daniel.Sanders at imgtec.com> wrote:
> >Hi Matthew,
> >
> >This assert is part of a long standing problem. In this case, the
> >problem is that the ABI is unknown because (at the moment) the ABI is
> >set as a side effect of selecting a CPU. Of course, no CPU has been
> >selected because you requested the CPU help text. This works for me:
> >       bin/llc -march=mipsel -target-abi=o32 -mcpu=help
> >although it does print the help text seven times at the moment. I'm not
> >sure why it prints it so many times but I expect it's once per
> >MipsSubtarget instantiation.
> >
> >You may also encounter this problem when using a 32-bit CPU with
> >-march=mips64el, or a 64-bit CPU with -march=mipsel since the backend
> >conflates having a 64-bit CPU or not with wanting to use a 64-bit ABI
> >or not.
> >
> >> -----Original Message-----
> >> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of
> >> Matthew Fernandez via cfe-dev
> >> Sent: 17 September 2015 10:42
> >> To: cfe-dev at lists.llvm.org
> >> Subject: [cfe-dev] Incorrect assumptions in MIPS backend
> >>
> >> Hi all,
> >>
> >> Running the following on an x86_64 Linux box triggers an assertion
> >failure:
> >>
> >>      llc -march=mipsel -mcpu=help </dev/null
> >>
> >> The assertion in question is the following:
> >>
> >>      llvm/lib/Target/Mips/MipsSubtarget.cpp:92-95
> >>
> >>      // Check if Architecture and ABI are compatible.
> >>      assert(((!isGP64bit() && (isABI_O32() || isABI_EABI())) ||
> >>              (isGP64bit() && (isABI_N32() || isABI_N64()))) &&
> >>             "Invalid  Arch & ABI pair.");
> >>
> >> It's possible my LLVM is not correctly configured to target MIPS, but
> >it still
> >> seems like this should not trigger an
> >> assertion failure. Is the MIPS backend assuming something it
> >shouldn't here?
> >>
> >> This is on a somewhat older revision, r218935. I tried to reproduce
> >this on the
> >> current tip, but had some difficulty
> >> building it (missing __cxa_* symbols during link; missing a
> >dependency?).
> >> Apologies if this issue is not reproducible on
> >> the tip.
> >>
> >> Thanks,
> >> Matt
> >>
> >> ________________________________
> >>
> >> The information in this e-mail may be confidential and subject to
> >legal
> >> professional privilege and/or copyright. National ICT Australia
> >Limited accepts
> >> no liability for any damage caused by this email or its attachments.
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 
> 
> ________________________________
> 
> The information in this e-mail may be confidential and subject to legal
> professional privilege and/or copyright. National ICT Australia Limited accepts
> no liability for any damage caused by this email or its attachments.