search for: _complex

On Mon, Oct 05, 2015 at 03:45:29PM -0700, Reid Kleckner wrote: > > > On 3 October 2015 at 02:29, Joerg Sonnenberger via llvm-dev > > > <llvm-dev at lists.llvm.org> wrote: > > > > while debugging assertions when building libm for 32bit Sparc, I hit > > the > > > > following IR: > > > > > > > > complex_mul_libcall: >

Hello > I don't know. I feel reluctant to generate different IRs for Win32 and > for Win64. Unfortunately, you should. Think about differences and between _Complex type and struct {double, double}. >From LLVM's point of view these are same types, however many ABIs have special rules for passing / returning _Complex, this is possible to handle in frontend only. > Since the C calling convention is the default for LLVM functions, I > thought that i...

Thanks, Anton! I didn't know about exceptions like _Complex that you mentioned. The only way to support them is to place the burden of correct parameter passing on the front-end, I understand that now. So, today I created a new transformation pass that makes sure that LLVM IR, which works alright with the default Win32 calling conventions, also plays nice...

Hi! I have discovered a problem with LLVM's interpretation of the Win64 calling convention w.r.t. passing of aggregates as arguments. The following code is part of my host application that is compiled with Visual Studio 2005 in 64-bit debug mode. noise4 expects a structure of four floats as its first and only argument, which is - in accordance with the specs of the Win64 calling convention -

I don't think an auto-generated name (along the lines of u or u2) for the anonymous structs would be helpful here. You can see that bindgen is already generating a placeholder name ("__bindgen_anon_1"). A meaningful name might be nice instead, but I get the impression that isn't an option here since that would break the C API. Can I ask, would it make sense for us to hard code

On Jul 23, 2008, at 12:58 PM, Chris Lattner wrote: > Again, there is a many to one mapping from C type to LLVM type and > not all C types that map onto the same llvm type are supposed to be > handled the same way. One concrete example is that some ABIs say that _Complex double is returned differently than struct { double r,i; }. -Chris

...er via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Can you give an example of where it would trigger in LTO and when should > not? > > You could imagine that __muldc3 might be implemented in C, and it might be implemented without using _Complex so that it can be compiled by a compiler without _Complex support. Instead of using a _Complex double return type, it would use a pointer outparam as the first parameter, and it would return that pointer as usual in RAX. Yes, this is a prototype mismatch and probably UB according to C, but this mig...

.... In this case, it means that F0 must be copied to integer return register R2. So this helper stub will work whether in reality fpff is compiled as mips16 or mips32. There are similar issues for mip32 code calling mips16 code. Return types that can be passed in registers include float, double, _Complex float and _Complex double. Parameter signatures of the form below need to be remapped: float double float, double float, float double, double double, float .section .mips16.call.fp.fpff,"ax", at progbits .align 2 .set nomips16 .set nomicromips .ent __call_stub_fp_fpff .type __cal...

...is also an issue related to SIMD signature matching when the vectorizer kicks in. Losing info from FE to BE is not good in general. > Yes, we cannot loose such information. In particular, the three examples I reported are all generating i64 in the scalar function signature: // Type 1 typedef _Complex int S; // Type 2 typedef struct x{ int a; int b; } S; // Type 3 typedef uint64_t S; S foo(S a, S b) { return ...; } On AArch64, the correspondent vector function signature in the three cases would be (for 2-lane unmasked vectorization): // Type 1: <4 x int> vectorized_foo(<4 x int&...

...ms of >> the original language types, and unfortunately some ABI's require >> different handling for types that are structurally equivalent. > > Just so I understand this better, for which ABIs is this the case?  It's > not for x86_64.  ARM, perhaps? Take, for example, _Complex long double on x86-64. Or unions on x86-64. :) -Eli >> See PR4246 for a plan to have generic helper codes for ABI lowering. > > It seems a bit complicated to me.  Wouldn't it be simpler to just encode > the language type information in metadata, or, if metadata isn't > a...

...gt; On Jul 23, 2008, at 12:58 PM, Chris Lattner wrote: > > Again, there is a many to one mapping from C type to LLVM type and > > not all C types that map onto the same llvm type are supposed to be > > handled the same way. > > One concrete example is that some ABIs say that _Complex double is > returned differently than struct { double r,i; }. Yes, that's a good point and something I had been missing. I know that the divide between responsibilities of frontends and backends is an endless debate. I tend to side with those who advocate for putting as much of the target...

...08, at 12:58 PM, Chris Lattner wrote: >>> Again, there is a many to one mapping from C type to LLVM type and >>> not all C types that map onto the same llvm type are supposed to be >>> handled the same way. >> >> One concrete example is that some ABIs say that _Complex double is >> returned differently than struct { double r,i; }. > > Yes, that's a good point and something I had been missing. > > I know that the divide between responsibilities of frontends and > backends is an endless debate. I tend to side with those who > advocate f...

Hi All, I have question about 'isUnsignedDIType' function on 'llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp' When we want to generate object file with dwarf debug format, clang can generates 'DW_ATE_lo_user' encoding for complex integer type as follow: "clang/lib/CodeGen/CGDebugInfo.cpp" llvm::DIType *CGDebugInfo::CreateType(const ComplexType *Ty) { ... if

...nfortunately, this wouldn't solve the problem that you think it does. For example, lets assume that LLVM allowed you to pass and return structs by value. Even with this, LLVM would not be able to directly implement all ABIs "naturally". For example, some ABIs specify that a _Complex double should be returned in two FP registers, but that a struct with two doubles in it should be returned in memory. By the time you lower to LLVM, all you have is {double,double}. In fact, there is no way, in general, to retain all the high level information in LLVM without flavoring the...

..., this wouldn't solve the problem that you think it > does. For example, lets assume that LLVM allowed you to pass and > return structs by value. Even with this, LLVM would not be able to > directly implement all ABIs "naturally". For example, some ABIs > specify that a _Complex double should be returned in two FP registers, > but that a struct with two doubles in it should be returned in memory. Even today, that must be special cased, i.e. the IR needs to be distinct between the two cases. As I understand it, the following is already legal, since vectors are first...

I think it would be possible to build a stripped-down C-with-extensions-only type representation that represents only the types that have interesting ABI implications. This includes several things not present in LLVM IR types: _Complex, union, flexible array members, alignment attributes, etc. We could either then use that library to generate LLVM IR, or embed it in the IR for use at call sites. You can exclude C++ because, for the most part, C++ types are either passed indirectly or as the analogous C struct would be passed. So...

As many of you will know, handling of struct arguments in LLVM is actually slightly more fiddly than you might expect. For targets where aggregates are always passed on the stack it's easy enough, the Clang ABI code marks these arguments as byval and the call lowering code in LLVM will copy the object to the stack when needed. There are more options for when the target has more complex ABI

...the current consensus. > > I would like to improve the situation so that passing LLVM aggregates > directly does the right thing when the LLVM struct type and C struct type > are effectively the same, so that custom frontend lowering is required for > hard cases involving things like _Complex and unions. Thanks for the response Reid. Looking more closely, it appears that the relationship between the target's ABI and whether aggregates are represented as byval structs, and whether these are coerced to something else in Clang's ABI handling)is more complex than I first described....

"Finkel, Hal J." <hfinkel at anl.gov> writes: > I think that it's really important that we're specific about the goals > here. Exactly what kinds of optimizations are we aiming to (more-easily) > enable? There certainly exists hardware with instructions that help > vectorize complex multiplication, for example, and having a builtin > complex type would

...t is also an issue related to SIMD signature matching when the vectorizer kicks in. Losing info from FE to BE is not good in general. > Yes, we cannot loose such information. In particular, the three examples I reported are all generating i64 in the scalar function signature: // Type 1 typedef _Complex int S; // Type 2 typedef struct x{ int a; int b; } S; // Type 3 typedef uint64_t S; S foo(S a, S b) { return ...; } On AArch64, the correspondent vector function signature in the three cases would be (for 2-lane unmasked vectorization): // Type 1: <4 x int> vectorized_foo(<4 x int&g...