similar to: [LLVMdev] Register allocation limitations

Hi Nikos, You can model your requirement in the *.td using RegisterClass as def SrcRegs : RegisterClass<"Src", [i32], 4, (add R0, R2, R4, R6 )>; def DstRegs : RegisterClass<"Dst", [i32], 4, (add R1, R3, R5, R7 )>; Thanks ~Umesh On Thu, Nov 7, 2013 at 8:25 PM, Stavropoulos Nikos < n.stavropoulos at think-silicon.com> wrote: > Hi all.

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) );

We have tried to make a version for llvm with native support for half floating point because we are interested in it. we added from http://half.sourceforge.net/ a half-float library and changed some records in llvm and the way that handles half float. we also used the patch that was on this thread http://llvm.1065342.n5.nabble.com/PATCH-OpenCL-half-support-tt40041.html so the clang front-end

Could you file a bug? On Wed, Feb 27, 2013 at 2:47 AM, Stavropoulos Nikos < n.stavropoulos at think-silicon.com> wrote: > 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(

hi all, i am trying to implement native support for fp16 in llvm-3.1 i have already used the opencl patch for clang so the IR that is generated is correct. i tried to add some code so the the fp16 type is handled correctly but no luck. We have a target that has native fp16 units and tried to run a simple program int main () { __fp16 a,b,c,d; a= 1.1; b=2.2; c=3.3;

Ping From: Mandeep Singh Grang [mailto:mgrang at codeaurora.org] Sent: Tuesday, February 03, 2015 4:34 PM To: 'llvmdev at cs.uiuc.edu' Cc: 'ghoflehner at apple.com'; 'apazos at codeaurora.org'; mgrang at codeaurora.org Subject: Question on Machine Combiner Pass Hi, In the file lib/CodeGen/MachineCombiner.cpp I see that in the function

Hi All, Recently I was doing some AArch64 work and noticed some cases where fmuls were not getting fused with fadds. Is there any particular reason that the AArch64 machine combiner doesn't do this like it does for add/mul? I am happy to work up a patch for this, but I wanted to make sure that there wasn't a good reason for it not already being there. FWIW, I see where GCC is doing

Hi. I have a system storage HP MSA 2012 with 12 drives in it: 8 drives are 2 Tb each and 4 are 1 Tb each. All of them are in array RAID 1+0. This storage is connected to two servers which use data, stored on the storage. So I'm using OCFS2 on these two nodes. Today, after long time of successfull work with it, I've found that it has a limit of 32000 subdirs. The trouble is I have more than

hi all I have a question about implementing a new instruction which does this function f(x) = x + ceilf (x) .x is a single float i have already added the instruction in my backend in the .td file def SUBCEIL_S : FFR<0x11, 0x3, 16, (outs FGR32:$fd), (ins FGR32:$fs), "frac.s\t$fd, $fs", [(set (f32 FGR32:$fd), (fadd (f32 FGR32:$fs ),(f32 (ceilf FGR32:$fs))))] >; it makes

Hello, I'm new on this list. First of all, thank you to all the developers of this great project! At the moment there is only an application that keeps me on both macos and windows, its name is PWGL a free environment for computer assisted composition in openGL. (http://www2.siba.fi/PWGL/) I'm running Ubuntu 8.04 and wine 0.9.59. I have to say that I also installed vcrun2005 and

On Fri, Sep 18, 2015 at 10:34 PM, Tim Northover <t.p.northover at gmail.com> wrote: > AArch64's fmadd instruction is fused, which means it can produce a > different result to the two operations executed separately. The C and > C++ standards do not allow such changes. Sorry, sloppy language on my part. I was aware of fmadd, but I was really asking about turning sequences like:

Hi, I offered some time ago to do some build cleanup. Today I did so and here's my slew of patches. Basically, they - touch ogg, vorbis, vorbis-tools and theora - fix a bunch of autotools issues - uniformize the use of them across the four - fix compile/link flags - use pkgconfig if it's available to detect flags - for vorbis-tools, generate and use config.h - add -uninstalled .pc stuff

Hi, I offered some time ago to do some build cleanup. Today I did so and here's my slew of patches. Basically, they - touch ogg, vorbis, vorbis-tools and theora - fix a bunch of autotools issues - uniformize the use of them across the four - fix compile/link flags - use pkgconfig if it's available to detect flags - for vorbis-tools, generate and use config.h - add -uninstalled .pc stuff

Currently it will always spill / restore the whole vreg but only spilling the parts that are actually live would be a nice addition in the future. Looking at r192119': if "mtlo" writes to $LO and sets $HI to an unpredictable value, then it should just have an additional (dead) def operand for $hi, shouldn't it? Greetings Matthias Am 10/8/13, 11:03 AM, schrieb Akira

Hi all, Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I am sending this email to give a status on GlobalISel progress and situation. We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. As explained during the last developer meeting, we are aiming at

I ran into an interesting problem when helping to land a scheduler .td file that my colleague had written. The problem that came up was that a multiply/add pair was not combined into an madd, but just for our CPU. Upon digging into it, the problem turned out to be that '(instregex "^SUB" ...' was matching "SUBREG_TO_REG" and incorrectly increasing the schedule length.

On Oct 8, 2013, at 2:06 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the

What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the other half would work. For example, this is an illegal sequence of instructions,

Hi All, I found some cases where a spill of a live range in a block is reloaded only in one of its successors, and there is no reload in other paths through other successors. Since the spill is reloaded only in a certain path, it must be okay to sink such spill close to its reloads. In the AArch64 code below, there is a spill(x2) in the entry, but this value is reloaded only in %bb.1, not in

This is just paraphrasing from D26602, so credit to Nicolai for first raising the issue there. float foo(float x, float y) { return x * (y + 1); } $ ./clang -O2 xy1.c -S -o - -target aarch64 -ffp-contract=fast | grep fm fmadd s0, s1, s0, s0 Is this a bug? We transformed the original expression into: x * y + x When x=INF and y=0, the code returns INF if we don't reassociate. With