search for: x86_fp80

...lvm::AlignTypeEnum, uint32_t, bool, const llvm::Type*) const: Assertion `AlignType == VECTOR_ALIGN && "Unknown alignment type!"' failed. The problem was that when i converted 'od' source code to llvm bitcode, long double type of 'od' source code was changed to x86_fp80 type in llvm bitcode and then llc on ARM target was not support x86_fp80 type. I think that long double type on ARM is 8 byte. (same as double type) When we use llvm on ARM target,(or other target not support x86_fp80) i think it might be better to convert long double type in C to double type in...

All, I should have chimed in earlier, but have been working on two more side-channel variants of this conversation. At the beginning the PNaCl team was strongly pushing for trying to keep platform ABI compatibility on all platforms while taking one portable bitcode stream as input. During the discussions we've had over the past few weeks it became obvious that that is simply not tractable,

...that the size of debug info variable and the described value matches (already caught a couple of bugs, both in my frontend and in LLVM itself). However, I've run into the following: size of passed value (80) does not match size of declared variable (128) call void @llvm.dbg.declare(metadata x86_fp80* %x, metadata !11, metadata !13), !dbg !14 %x = alloca x86_fp80, align 16 !11 = !DILocalVariable(name: "x", scope: !4, file: !1, line: 2, type: !12) !12 = !DIBasicType(name: "long double", size: 128, align: 128, encoding: DW_ATE_float) !13 = !DIExpression() which happens beca...

...const llvm::Type*) const: > Assertion `AlignType == VECTOR_ALIGN && "Unknown alignment type!"' > failed. > > The problem was that > when i converted 'od' source code to llvm bitcode, long double type > of 'od' source code was changed to x86_fp80 type in llvm bitcode and > then llc on ARM target was not support x86_fp80 type. > > I think that long double type on ARM is 8 byte. (same as double type) > > When we use llvm on ARM target,(or other target not support x86_fp80) > i think it might be better to convert long doubl...

Hi, I am working on x86-64 and am working with a C frontend that folds sizeof(long double) into 12. For now, I am trying to avoid modifying that part of the frontend by finding a way to tell LLVM that 12 bytes are allocated for x86_fp80. To explore this, I tried an experiment with llvm-gcc: % llvm-gcc --version | head -1 llvm-gcc (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2.8) % llvmc --version Low Level Virtual Machine (http://llvm.org/): llvm version 2.8 Optimized build. Built Oct 25 2010 (10:39:46). Hos...

...uint32_t, bool, const llvm::Type*) const: Assertion `AlignType == > VECTOR_ALIGN && "Unknown alignment type!"' failed. > The problem was that > when i converted 'od' source code to llvm bitcode, long double type of > 'od' source code was changed to x86_fp80 type in llvm bitcode and then > llc on ARM target was not support x86_fp80 type. > I think that long double type on ARM is 8 byte. (same as double type) > When we use llvm on ARM target,(or other target not support x86_fp80) > i think it might be better to convert long double type in C...

...lvm::AlignTypeEnum, uint32_t, bool, const llvm::Type*) const: Assertion `AlignType == VECTOR_ALIGN && "Unknown alignment type!"' failed. The problem was that when i converted 'od' source code to llvm bitcode, long double type of 'od' source code was changed to x86_fp80 type in llvm bitcode and then llc on ARM target was not support x86_fp80 type. I think that long double type on ARM is 8 byte. (same as double type) When we use llvm on ARM target,(or other target not support x86_fp80) i think it might be better to convert long double type in C to double type in...

Hi Joel, > I am working on x86-64 and am working with a C frontend that folds > sizeof(long double) into 12. For now, I am trying to avoid modifying that > part of the frontend by finding a way to tell LLVM that 12 bytes are > allocated for x86_fp80. I think the "fact" that x86 long double is 16 byte aligned on x86-64 is hard-wired in. I'm not sure how hard this would be to control via a command line option (i.e. -m96bit-long-double). > Looking inside test.ll, I see f80:128:128, but I also see sizeof(long > double)*5 fol...

Hi, I've been hacking around something missing in the assemble for the mingw-w64 targets the tfloat variable. I did some research into the llvm sources and did see x86_fp80 which seems to be the same thing. Can we support the .tfloat variable or the alternative ? Or is it under another name? I've tried using .x86_fp80 instead but to no avail. :/ Here is how tfloat is being used in mingw-w64 and how I am hacking around it with a very dirty .double Date: Wed, 1 J...

On Nov 1, 2010, at 12:03 PM, Jonas Maebe wrote: > > On 01 Nov 2010, at 18:37, Duncan Sands wrote: > >> I think the "fact" that x86 long double is 16 byte aligned on x86-64 is >> hard-wired in. > > Note that it's not just about alignment, but mainly about the reserved storage size. > >> I'm not sure how hard this would be to control via a

Hi Duncan, On Mon, 1 Nov 2010, Duncan Sands wrote: > > Does llvm-gcc not intend to support -m96bit-long-double? > > Please open a bug report asking for support for -m96bit-long-double, > to ensure this issue is not forgotten. Given the thread that followed this post, I'm not sure whether you still want a bug report. Is the plan to fix -m96bit-long-double or just remove it

Hi Joel, >>> Does llvm-gcc not intend to support -m96bit-long-double? >> >> Please open a bug report asking for support for -m96bit-long-double, >> to ensure this issue is not forgotten. > > Given the thread that followed this post, I'm not sure whether you still > want a bug report. Is the plan to fix -m96bit-long-double or just remove > it and expect

...Type*) const: Assertion `AlignType == >> VECTOR_ALIGN && "Unknown alignment type!"' failed. >> >> The problem was that >> when i converted 'od' source code to llvm bitcode, long double type >> of 'od' source code was changed to x86_fp80 type in llvm bitcode >> and then llc on ARM target was not support x86_fp80 type. >> >> I think that long double type on ARM is 8 byte. (same as double type) >> >> When we use llvm on ARM target,(or other target not support x86_fp80) >> i think it might be bett...

Hi Jonas, >> I think the "fact" that x86 long double is 16 byte aligned on x86-64 is >> hard-wired in. > > Note that it's not just about alignment, but mainly about the reserved storage size. actually it is about the alignment, since the reserved storage size is (in LLVM) the number of bytes needed to store the type (i.e. 10 bytes) rounded up by the alignment.

...< >> llvm-dev at lists.llvm.org> wrote: >> >>> Looking at the code in clang CGDebugInfo just passes through the width >>> of the type as it is described by the TypeInfo, which in turn is defined by >>> the Target. At the moment I do not understand why an x86_fp80 is reported >>> to be 128 bits wide. (Since it’s a type natively supported by LLVM >>> http://llvm.org/docs/LangRef.html#floating-point-types I would have >>> expected it to be more like size=80, align=128) >>> >>> This looks like a bug to me and the deb...

Hi, Can anyone help me understand that LLVM IR has "target independence" ? 1. When we talk about "target", we mean something like Instruction Set Architecture ? 2. The front-end may generate IR code such as x86_fp80, so the IR is actually not fully target-independent? It contains information about the target, and the front-end should also be aware of this? Thank you! Hao -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20...

...5 at 8:38 AM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Looking at the code in clang CGDebugInfo just passes through the width of > the type as it is described by the TypeInfo, which in turn is defined by > the Target. At the moment I do not understand why an x86_fp80 is reported > to be 128 bits wide. (Since it’s a type natively supported by LLVM > http://llvm.org/docs/LangRef.html#floating-point-types I would have > expected it to be more like size=80, align=128) > > This looks like a bug to me and the debug info should describe an x86_fp80 >...

...t;> *Sent:* Monday, November 02, 2015 4:10 PM >> *To:* Keno Fischer >> *Cc:* llvm-dev >> *Subject:* Re: [llvm-dev] Representing X86 long double in Debug Info >> >> >> >> To come back to the original question: Doesn't LLVM know somewhere that >> x86_fp80 requires 128 bits of storage? (eg: how does it layout the call >> argument for an x86_fp80 if it's not being passed in a register? How does >> it layout the stack containing one of these?) >> >> I /imagine/ somewhere in LLVM knows about the need for 128 bits of >>...

On 01 Nov 2010, at 18:37, Duncan Sands wrote: > I think the "fact" that x86 long double is 16 byte aligned on x86-64 is > hard-wired in. Note that it's not just about alignment, but mainly about the reserved storage size. > I'm not sure how hard this would be to control via a > command line option (i.e. -m96bit-long-double). Is there no different way to go about

Duncan, could this be related to your recent work? Chuck, this is unlikely to be a x86 specific problem. Please file a bug. Thanks! Evan On Dec 6, 2007, at 5:06 PM, Chuck Rose III wrote: > Hola LLVMers, > > One of the corner-case features of the Hydra language I work on are > Boolean vectors of length 2, 3, or 4 which I’ve been representing as > either <2 x i1> or