Dear LLVMers, I need your help to understand my problem: I'm compiling a code for 2 different targets (x86_64 and sparc). In this code, I define a union which is basically a int32 and a function which returns this union. The compilation of this code produces 2 different IRs : * for x86, the return type is int32, * for sparc, the return type is a struct (first argument of the function with attribute sret). I guess an optimization pass is called to simplify the return type in first case but i have no idea which one ? Does anybody have an explanation ? Thanks! Julien
This seems like the case of returning struct in registers. This is usually dictated by the ABI, not by a compiler optimization, for compatibility reasons. Kevin On Wed, Apr 19, 2017 at 1:38 AM, Julien Schmitt via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Dear LLVMers, > > I need your help to understand my problem: > > I'm compiling a code for 2 different targets (x86_64 and sparc). In this > code, I define a union which is basically a int32 and a function which > returns this union. The compilation of this code produces 2 different IRs : > > * for x86, the return type is int32, > > * for sparc, the return type is a struct (first argument of the function > with attribute sret). > > I guess an optimization pass is called to simplify the return type in > first case but i have no idea which one ? > > Does anybody have an explanation ? > > Thanks! > > Julien > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170419/ef14bcbb/attachment.html>
On 19 April 2017 at 01:38, Julien Schmitt via llvm-dev <llvm-dev at lists.llvm.org> wrote:> I guess an optimization pass is called to simplify the return type in first > case but i have no idea which one ? > > Does anybody have an explanation ?The IR-level return (& arg) type is a complex contract between Clang and each LLVM backend. Clang knows which registers (or stack) it wants any object to be returned or passed in, and knows how the LLVM backend will treat any type, so it carefully chooses the type to get the right properties. Sometimes it even adds dummy arguments for padding. Since this code needs to know so much about the backend, it's different for each target (in Clang's lib/CodeGen/TargetInfo.cpp). X86 & Sparc just happen to pick different types for your union. Cheers. Tim,