[PATCH] D72189: [SystemZ] Support -msoft-float

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand added a comment.

In D72189#1852408 <https://reviews.llvm.org/D72189#1852408>, @jonpa wrote:

> > If soft-float, then we have *no* VectorABI!
>
> Oh! I misunderstood your previous comment "with -msoft-float, GCC also falls back to the 16-byte vector alignment, so we must match that for ABI compatibility" to mean that (source code) vectors should be aligned to 16 bytes in memory.


Yes, that's what I meant.  Maybe what's confusing is that on our platform, the "vector ABI" only has an 8-byte alignment for vector types (which is more efficient), while the "old" (non-vector) ABI has a 16-byte alignment (for historical reasons).

>> What's the difference in assembler? Could this be because you've implemented the VectorABI check the wrong way around? (If soft-float, then we have *no* VectorABI!)
> 
> Also with the latest updates of the patch, I see for this function:
> 
>   typedef int v4si __attribute__ ((vector_size (16)));
>   v4si foo(v4si *Dst) {
>     return *Dst;
>   }
>   
> 
> 
> 
> 
>   gcc -S -O3 -march=z14 -msoft-float
>   
>   foo:
>     lmg     %r4,%r5,0(%r3)
>     stmg    %r4,%r5,0(%r2)
>     br      %r14
>   
> 
> 
> 
> 
>   clang -S -O3 -march=z14 -msoft-float
>   
>   foo:                                    # @foo
>   l       %r0, 0(%r2)
>   l       %r3, 4(%r2)
>   l       %r4, 8(%r2)
>   l       %r5, 12(%r2)
>   lr      %r2, %r0
>   br      %r14
>   
> 
> 
> It seems that gcc is loading from %r3, while clang is loading from %r2, and gcc is returning on the stack, while clang seems to be returning in registers.

That looks completely broken.   Note that current clang, when using the non-vector ABI, does generate code that is compatible to what GCC generates, so this must have been broken by this patch somehow.  (Possibly the problem is when checking for the vector ABI in TargetInfo.cpp, see inline comment.



================
Comment at: clang/lib/CodeGen/TargetInfo.cpp:9935
+    bool SoftFloat = CodeGenOpts.FloatABI == "soft";
+    return SetCGInfo(new SystemZTargetCodeGenInfo(Types, HasVector, SoftFloat));
   }
----------------
Hmm.  In the SoftFloat case, we also should be setting HasVector to false here.  Maybe that even explains the incorrect assembler code you're seeing.

(Maybe it would be best after all to reset the HasVector flag globally, then we wouldn't have the problem of forgetting all these cases ...)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72189/new/

https://reviews.llvm.org/D72189