similar to: Clang for the PlayStation 2

On Mon, 3 Sep 2018 at 13:31, Tim Northover <t.p.northover at gmail.com> wrote: > So the next step is to debug where Mips is producing those TruncIntFP > nodes. There'll be some constraint it's not checking or an unexpected > node type, probably related to -msingle-float. I'm afraid I'm not sure > what yet. > I'm reasonably sure the function producing that

Is the llvm backend (legalize, isel, etc.) currently capable of handling type f128? I am trying to emit a call to __subtf3 when I compile the following bitcode: define fp128 @f1(fp128 %a0, fp128 %a1) nounwind readnone { entry: %sub = fsub fp128 %a0, %a1 ret fp128 %sub } This is for the Mips backend.

I figured it out. I was using this implementation of __chkstk from compiler-rt: DEFINE_COMPILERRT_FUNCTION(___chkstk) push %rcx cmp $0x1000,%rax lea 16(%rsp),%rcx // rsp before calling this routine -> rcx jb 1f 2: sub $0x1000,%rcx test %rcx,(%rcx) sub $0x1000,%rax cmp $0x1000,%rax ja 2b 1:

On Thu, May 27, 2010 at 7:09 PM, John Criswell <criswell at uiuc.edu> wrote: > I believe what you want is documented here: > > http://llvm.org/docs/LangRef.html#datalayout > Just a note, since it might be a bug on the backend or documentation. It says on the documentation that size for f is either 32 or 64, however, sparc has 64 and 128. -- PMatos

On Fri, 7 Sep 2018 at 16:59, Tim Northover <t.p.northover at gmail.com> wrote: > $ clang -target mips64el-img-linux -mcpu=mips3 -S -o- -Os tmp.c > Actually, I just tried your flags; you're missing `-msingle-float`, which is what reproduces the crash on my end. Without it there is no problem. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, May 27, 2010 at 11:18 AM, Paulo J. Matos <pocmatos at gmail.com> wrote: > On Thu, May 27, 2010 at 7:09 PM, John Criswell <criswell at uiuc.edu> wrote: >> I believe what you want is documented here: >> >> http://llvm.org/docs/LangRef.html#datalayout >> > > Just a note, since it might be a bug on the backend or documentation. > It says on the

On Thu, 6 Sep 2018 at 20:01, Tim Northover <t.p.northover at gmail.com> wrote: > I just did a very quick experiment where I made lowerFP_TO_SINT and > lowerFP_TO_SINT_STORE return SDValue() (which is the marker for "I > don't want to handle this"). I just tried this, but the compiler still crashes with the same error. Maybe our experiments were different. To make

On Mon, Apr 13, 2020 at 1:16 PM Jon Roelofs via llvm-dev < llvm-dev at lists.llvm.org> wrote: > As an update, after lots of fixes from a number of different people > (thanks everyone!), the current list of false-positives on `ninja > check-llvm` for the more stringent Gotcha A diagnostic is: > > LLVM :: Analysis/CostModel/X86/vselect-cost.ll > LLVM ::

Hi Tim, Thanks for the hint. I tried the following, (it's a C interface since that's what I need it for) where a and b are the top and bottom halves of the 128 bit value, LLVMValueRef TestConst(LLVMContextRef C, uint64_t a, uint64_t b) { Type *ty = Type::getFP128Ty(*unwrap(C)); ArrayRef<uint64_t> ar[2] = {a,b}; APInt ai(128,*ar); APFloat quad(APFloat::IEEEquad(), ai);

On Feb 16, 2009, at 6:36 PMPST, Chris Lattner wrote: > > On Feb 16, 2009, at 6:12 PM, aparna kotha wrote: > >> I am new to llvm and am stuck up with a problem. >> I am trying to initialize a Value* of type fp128 having the value 0 >> >> I am using the following construct >> >> ConstantFP::get(APFloat(APInt(128,0,false))); >> >> This is

Hello, I'm new to this mailing list and fixing llvm bugs for Android. Can anyone point me to any previous discussion or work related to the following bug? https://llvm.org/bugs/show_bug.cgi?id=23897 I am testing my patch to llvm to make f128 values stay in SSE registers instead of being split into two i64 values. I have tried to add a register class FR128 to hold f128 values for the x86_64

I am new to llvm and am stuck up with a problem. I am trying to initialize a Value* of type fp128 having the value 0 I am using the following construct ConstantFP::get(APFloat(APInt(128,0,false))); This is returning a double instead of a float and I am confused. Thanks a lot for your help. -- -- Aparna -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, Just wondering if it's possible to construct a 128 bit quad precision floating point constant without converting the value back to a string. Cheers Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190410/a527f240/attachment.html>

On Thu, 6 Sep 2018, 16:31 Tim Northover, <t.p.northover at gmail.com> wrote: > > The PS2, for what it's worth, only has an i32 -> f32 instruction, so I > think there's an impedance mismatch somewhere. > > This is also a fairly common situation. If the operation can be > emulated with a reasonably small number of native instructions you can > often get LLVM to

On 7 March 2017 at 17:58, Reid Kleckner <rnk at google.com> wrote: > Today, the vast majority of target in Clang coerce aggregates passed this > way into appropriate word-sized types. They all use their own custom > heuristics to compute the LLVM types used for the coercions. It's terrible, > but this is the current consensus. > > I would like to improve the situation

Hello, To any out-of-tree targets, please be aware that I intend to commit a patch that will break the build of any target implementing TargetLoweringBase::isFMAFasterThanMulAndAdd, for the reasons described below. (Basically, the current interface definition is broken and not followed, and no in-tree target was doing the right thing with it, so it is unlikely any out-of-tree target is either...)

On Feb 16, 2009, at 6:12 PM, aparna kotha wrote: > I am new to llvm and am stuck up with a problem. > I am trying to initialize a Value* of type fp128 having the value 0 > > I am using the following construct > > ConstantFP::get(APFloat(APInt(128,0,false))); > > This is returning a double instead of a float and I am confused. > > Thanks a lot for your help. FP128Ty

Hi Akira > Is the llvm backend (legalize, isel, etc.) currently capable of > handling type f128? > I am trying to emit a call to __subtf3 when I compile the following bitcode: It depends... There is some generic code here and there which can handle f128, but some parts are still missed. You might need to fill them... -- With best regards, Anton Korobeynikov Faculty of Mathematics and

Hello, I am trying to find out where the complete documentation for the TargetDescription string documentation is. I am reading the tutorial and looking at the sparc backend at the same time and there are some discrepancies. Therefore the documentation would be extremely valuable but I can't seem to find it. In the tutorial it shows the string "E-p:32:32-f128:128:128", but the real

In "Writing an LLVM Compiler Backend", there's some discussion of the TargetDescription string, but it doesn't explain the examples I look at. For instance, in the description of the PowerPC, I see "E-p:64:64-f64:64:64-i64:64:64-f128:64:128-n32:64" What's "preferred alignment" versus "ABI alignment"? What are the 3 figures following the