similar to: '__builtin_nanl' and soft-FP64 support

On 9/25/2017 5:35 AM, Martin J. O'Riordan via llvm-dev wrote: > > I am seeing failures in two tests after migrating to v5.0 final, these > are: > > std/language.support/support.limits/limits/numeric.limits.members/quiet_NaN.pass.cpp > > and: > > std/language.support/support.limits/limits/numeric.limits.members/signaling_NaN.pass.cpp > > However, these are new

Most of codegen is already FP64-ready. There are a few edge-cases that I ran into, many of which can apply even to non-fp64-enabled programs (although the double-wide registers are not very common without fp64). I've yet to give this a full piglit run, but wanted to send these out in case someone wanted to comment. They do not depend on the preliminary core fp64 work. Ilia Mirkin (5):

Hi, >> My target supports only f64 at the moment. >> Question: How can I tell LLVM that float is the same as double on my >> target? May be by assigning the same register class to both MVT::f32 ?> and MVT::f64? >Just don't assign a register class for the f32 type. This is what the >X86 backend does when it is in "floating point stack mode". This will

Is there anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) ... case ISD::SINT_TO_FP: case ISD::UINT_TO_FP: case ISD::EXTRACT_VECTOR_ELT: Action = TLI.getOperationAction(Node->getOpcode(), Node->getOperand(0).getValueType());

On Mar 19, 2010, at 12:23 PM, Villmow, Micah wrote: > Is there anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? I don't see any. > > In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) > > ... > case ISD::SINT_TO_FP: > case ISD::UINT_TO_FP: > case ISD::EXTRACT_VECTOR_ELT: > Action =

On Tue, 10 Oct 2006, Roman Levenstein wrote: >>> such a call instruction? >> >> Why not just make the asm string be "call __fsub64"? > > Well, of course it would be the best solution. But the interesting part > is that I need to generate the machine code directly because for > different reasons use of a system assembler is not an option. As a ok. >

On Mon, Jun 23, 2014 at 2:45 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: >> There are a lot of MIPS ABIs. > > Yes, and we've discovered that there seem to be incompatible extensions to some of these ABI's too. :) > >> I'm pretty sure Imagination Technologies working up a new abi right now. > > Not exactly. We're not working on any

> So in summary, each step is ABI compatible with the previous step. The linker will ensure that the end-user doesn't try to do the second step before the first step is finished since it will refuse to link a binary that contains both O32 and O32+fp64. It will produce an O32 binary given a combination of O32+fpxx, and similarly a O32+fp64 binary given a combination O32+fpxx and O32+fp64.

Hi Jakob and David, The for-loop inside multiclass definition does not have to add extra abstraction layer. As in the pseudo codes that David wrote earlier (see below), it only condenses the repetitive 'def' statements inside the multiclass definition into a more compact and less copy-paste style form, instead of encapsulating them somewhere outside the multiclass definition. I believe

On Oct 8, 2011, at 6:19 AM, Che-Liang Chiou wrote: > I understand if you don't want an extra layer of abstraction (which > adds extra looking-ups to someone reading td files), but I think we > can have for-loop inside a multiclass without abstractions. > > -------------------- > multiclass sse_binop<opcode> { > for type = [f32, f64, v4f32, v2f64] > regclass

This patch is needed to allow klibc to be compiled on a mips compiler configured to use the FPXX ABI (which is in GCC 5). In that ABI the odd numbered FPU registers cannot be used directly, but they can be accessed using the double word sdc1 and ldc1 instructions. See this page for more info: https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking Signed-off-by: James Cowgill

i have this code typedef long long L; typedef integer I; void test2(auto L p0, auto L p1, auto L p2, auto L p4, ...) { va_list select; va_start (select, p4); report( va_arg(select,L) ); report( va_arg(select,I) ); report( va_arg(select,L) );

Hi Hans, All pushed. I made a few additional fixes and improvement to fp64 immediate handling along the way, but all your commits were fine as-is. (Except that they enabled fp64 immediates on nv50 implicitly which is wrong -- there are no immediate-taking variants on nv50, so I fixed that glitch. But only the G200 can do fp64 in the first place, and nouveau doesn't actually expose it. Corner

Hi All, This series implements using double immediates in the nouveau codegen code. This turns the following (nvc0) code: 1: mov u32 $r2 0x00000000 (8) 2: mov u32 $r3 0x3fe00000 (8) 3: add f64 $r0d $r0d $r2d (8) Into: 1: add f64 $r0d $r0d 0.500000 (8) This has been tested with the 2 double shader tests which I just send to the piglet list. On a gk208 (gk110 / SM35)

Che-Liang Chiou <clchiou at gmail.com> writes: > My purpose is to eliminate copy-paste style of programming in td files > as much as possible, but only to a point that the new language > constructs do not create too much overhead/readability-downgrade. Yes! > In other words, I am targeting those low-hanging fruit of copy-paste > programmings in td files that are eliminated

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Untested beyond compiling a few shaders to see if they look like they might work. nvdisasm agrees with envydis's decoding of these things. Will definitely get ahold of a G200 to run tests on before pushing this. .../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 94 ++++++++++++++++++---

Hi all, What changes to LLVM are needed to support arithmetic for PPCDoubleDouble? arithmeticOK == false for PPCDoubleDouble leads e.g. to assert "Compile-time arithmetic does not support these semantics" when compiling the next function on PowerPC with clang: double quiet_NaN() { return 4.94065645841246544176568792868221e-324L; } -- Regards, Konstantin

On Mon, 9 Oct 2006, Roman Levenstein wrote: > I'm now ready to implement the FP support for my embedded target. cool. > My target supports only f64 at the moment. > Question: How can I tell LLVM that float is the same as double on my > target? May be by assigning the same register class to both MVT::f32 > and MVT::f64? Just don't assign a register class for the f32 type.

Hi, I'm now ready to implement the FP support for my embedded target. My target supports only f64 at the moment. Question: How can I tell LLVM that float is the same as double on my target? May be by assigning the same register class to both MVT::f32 and MVT::f64? But FP is supported only in the emulated mode, because the target does not have any hardware support for FP. Therefore each FP

On Wed, Jun 18, 2014 at 2:03 AM, Matheus Almeida <Matheus.Almeida at imgtec.com> wrote: >> Why Imagination Technologies do not offer the latest MIPS ABI document download link just like the ISA docs? > It's something we're considering to do and the documents should be available at some point in the [hopefully] not too distant future. > >> then why GCC disagree with