RalfJung wrote:
> Generally clang-level warnings/errors are more user friendly then the
> llvm-level errors (but both may be useful for other frontends).
What would be really nice is if the LLVM backend could tell the frontend about
the error rather than reporting it itself, that way frontends
RalfJung wrote:
> I'm not yet convinced that llvm is the right place for this error message.
> There's quite a lot of test changes that I presume needed to make and at
> least the LTO use case looks like we don't want to require extra information.
> I'd also prefer this to be a front-end error
RalfJung wrote:
Yeah ideally LLVM would provide APIs where frontends can explicitly query that
kind of information, and then provide nice errors with context. What this PR
does is only the second-best think, in my eyes.
But very few frontends can afford having an expert for each and every
arc
RalfJung wrote:
> converting llvm errors to clang errors.
I assume you didn't also add those errors to all the other frontends, so every
time you do this (assuming you actually remove the LLVM error at that point)
you risk introducing bugs into other frontends (if they were relying on LLVM to
RalfJung wrote:
As a Rust compiler dev, this part of LLVM feels extremely fragile. If we do
anything wrong, LLVM will just use *some* ABI, and things will keep working for
some situations, but really we have subtle ABI bugs that will eventually bite
our users. The rules we have to follow are n
RalfJung wrote:
RISC-V has similar checks here:
https://github.com/llvm/llvm-project/blob/ed572f2003275da8e06a634b4d6658b7921e8334/llvm/lib/Target/RISCV/RISCVISelLowering.cpp#L88-L100
So maybe the ARM checks could be added in a similar place? RISC-V handles ABI
variants in a very clean way, an
https://github.com/RalfJung edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/RalfJung edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -311,11 +311,15 @@ ARMBaseTargetMachine::getSubtargetImpl(const Function &F)
const {
// function that reside in TargetOptions.
resetTargetOptions(F);
I = std::make_unique(TargetTriple, CPU, FS, *this, isLittle,
-F.hasMinSi
@@ -311,11 +311,15 @@ ARMBaseTargetMachine::getSubtargetImpl(const Function &F)
const {
// function that reside in TargetOptions.
resetTargetOptions(F);
I = std::make_unique(TargetTriple, CPU, FS, *this, isLittle,
-F.hasMinSi
RalfJung wrote:
@chrisnc what are the next steps here?
Maybe one solution, for maximum compatibility, would be to not emit any
warnings when `Options.FloatABIType` is left at `FloatABI::Default`, but if it
is explicitly set to `FloatABI::Hard` and the required target features are
missing, tha
RalfJung wrote:
> there doesn't seem to be a mechanism to issue a warning from within LLVM
> codegen, only to error.
RISC-V does `errs() << "Hard-float 'f' ABI can't be used for a target that "
...` and that acts as a warning. It just prints a message to stderr. It's not
pretty but it's bet
12 matches
Mail list logo
