rengolin added a comment.

In https://reviews.llvm.org/D38479#886587, @efriedma wrote:

> 1. We don't correctly ignore inline asm clobbers for registers which aren't 
> allocatable (https://bugs.llvm.org/show_bug.cgi?id=30792)


This looks like a different (but related) issue. That should be fixed in the 
back-end, regardless of the new error messages.

> 2. We don't diagnose calls which need vector registers according to the C 
> calling convention.

The function that checks for it returns true for vectors 
(`lib/Sema/SemaExprCXX.cpp:7487`). However, the tests cover floating point, but 
they don't cover vector calls (arm_neon.h).

> 3. We don't diagnose operations which have to be lowered to libcalls which 
> need vector registers according to the C calling convention (fptosi, 
> @llvm.sin.*, etc.).

Yup. That's bad.

> All three of these could be addressesed in the AArch64 backend in a 
> straightforward manner.

I worry about declarations and front-end optimisations, which may move the line 
info to a completely different place (where it's used, for example). But I have 
no basis for that worry. :)

> Diagnosing floating-point operations in Sema in addition to whatever backend 
> fixes we might want is fine, I guess, but I don't really like making 
> "-mgeneral-regs-only" into "-mno-implicit-float" plus some diagnostics; other 
> frontends don't benefit from this checking, and using no-implicit-float is 
> asking for an obscure miscompile if IR generation or an optimization 
> accidentally produces a floating-point value.

I agree with both statements. But it would be good to have the errors in Sema 
in addition to the back-end fixes, if there are cases where Clang's diagnostics 
is more precise on line info and carat position.



================
Comment at: lib/Sema/SemaExprCXX.cpp:7477
+static bool typeHasFloatingOrVectorComponent(
+    QualType Ty, llvm::SmallDenseMap<const RecordType *, bool, 8> &TypeCache) {
+  if (Ty.isNull())
----------------
The `TypeCache` object seems local.

It doesn't look like it needs to survive outside of this function, as per its 
usage and the comment:

    // We may see recursive types in broken code.

and it just adds another argument passing.


https://reviews.llvm.org/D38479



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to