[cfe-dev] The x64 ABI lowering, direct pass of upper 8-bytes, can it happen?

[Christoffer Lernö via cfe-dev]

That’s interesting (and slightly confusing) 

I could only see this happening if Layout.getFieldOffset(idx) would return a value greater than zero for the b member. (TargetInfo.cpp, line 3071)

However, that seemed unlikely… What I forgot to do though was to take C++ into account. It appears that for C++ the offset is indeed 8 for b (whereas for C it is 0). So then this behaviour is strictly something that can occur in C++ code.

This could possibly be added to the code as a comment to clarify it to readers.

Christoffer
AEGIK / www.aegik.se

> On 12 Nov 2020, at 23:13, Craig Topper <craig.topper at gmail.com> wrote:
> 
> Adding an assert(0) inside that if fires on this test case from clang/test/CodeGenCXX/x86_64-arguments.cpp
> 
> // PR5831
> // CHECK-LABEL: define void @_Z2f34s3_1(i64 %x.coerce)
> struct s3_0 {};
> struct s3_1 { struct s3_0 a; long b; };
> void f3(struct s3_1 x) {}
> 
> ~Craig
> 
> 
> On Thu, Nov 12, 2020 at 1:06 PM Christoffer Lernö via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> I apologize for spamming with so many questions, but this really confusing me.
> 
> In X86_64ABIInfo::classifyArgumentType we have this code:
> 
> >   case Integer:
> >     ++neededInt;
> >     // Pick an 8-byte type based on the preferred type.
> >     HighPart = GetINTEGERTypeAtOffset(CGT.ConvertType(Ty), 8, Ty, 8);
> > 
> >     if (Lo == NoClass)  // Pass HighPart at offset 8 in memory.
> >       return ABIArgInfo::getDirect(HighPart, 8);
> >     break;
> 
> Zooming in on the ”Lo == NoClass”. As far as I can tell this can only happen in the case where a struct has padding in front, and the first real integer parameter is actually 64 bits in.
> 
> I admit I have no idea how to construct such a type in C to trigger this. Since Clang has a non-trivial amount of code to handle this I am wondering what I’m missing. (I’ve looked through the x86 test cases as well but was unable to find a test case for this particular situation. I might have overlooked something though)
> 
> 
> /Christoffer
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201113/b3adcf08/attachment-0001.html>