similar to: [LLVMdev] Poison values [WAS: Re: rotate]

Andy, Here is the left circular shift operator patch. I apologize to the reviewer in advance. The patch has a good bit of fine detail. Any comments/criticisms? Some caveats... 1) This is just the bare minimum needed to make the left circular shift operator work (e.g. no instruction combining). 2) I tried my best to select operator names in the existing style; please feel free to change them as

On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > Parts of my patch did make it into trunk about a year after, but others > did not. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

Well, we like the operator because it maps cleanly to Fortran's ISHFTC intrinsic. There must also be other compilers out there, maybe catering to cryptos, that have their own intrinsic for circular shift in other languages. It seems wasteful for an optimizer to break apart an intrinsic into its elemental pieces in order for LLVM to put them back together. This was done in our compiler for some

On Tue, Jul 31, 2012 at 8:42 AM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > Andy, > > Here is the left circular shift operator patch. I apologize to the reviewer > in advance. The patch has a good bit of fine detail. Any > comments/criticisms? > > Some caveats... > > 1) This is just the bare minimum needed to make the left circular shift > operator

On Jul 31, 2012, at 3:04 AM, Andy Gibbs <andyg1001 at hotmail.co.uk> wrote: > On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: >> Hey Andy, >> >> I proposed a similar patch to LLVM (left circular shift) around 10/2011. >> Parts of my patch did make it into trunk about a year after, but others >> did not. >> >> At that time, my

On Mar 1, 2012, at 3:04 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > On Thu, Mar 1, 2012 at 5:30 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > Aligning the stack to 32 bytes when there are auto AVX vector variables present shouldn't necessarily break the x86-64 ABI, as long as smaller auto variables remain properly aligned. A similar approach

Even if you explicitly specify –stack-alignment=16 the aligned movs are still generated. It is not an issue related to ABI. See my original mail: ./llc -mattr=+avx -stack-alignment=16 < basic.ll | grep movaps | grep ymm | grep rbp vmovaps -176(%rbp), %ymm14 vmovaps -144(%rbp), %ymm11 vmovaps -240(%rbp), %ymm13 - Elena From: Cameron McInally

On Fri, Jun 14, 2019 at 7:10 PM Chris Lattner <clattner at nondot.org> wrote: > > > On Jun 14, 2019, at 4:06 PM, Cameron McInally <cameron.mcinally at nyu.edu> > wrote: > > > > On Fri, Jun 14, 2019 at 6:58 PM Chris Lattner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Jun 14, 2019, at 3:24 PM, Eli Friedman via

In the section about poison values, the LLVM language reference manual says: "Values other than phi nodes depend on their operands." This implies that a select instruction's output can be poisoned by its not-selected argument value. If select were poisoned only by its selected argument, we would expect this fact to be mentioned specifically, as it is for phi. Next I'll

This is fundamentally different than the problems we’re trying to handle with the constrained FP intrinsics. The constrained FP intrinsics were necessary because LLVM IR otherwise assumes that FP instructions do not have side effects. In the case of integer divide-by-zero, the optimizer generally recognizes this as a possibility and avoids introducing it (through speculation, for instance). But if

Hi, can you please check the problem is fixed by r195125? On Tue, Nov 19, 2013 at 2:35 PM, Alexander Potapenko <glider at google.com> wrote: > Hi Cameron, > > I'm planning to address this issue today. > > HTH, > Alex > > On Mon, Nov 18, 2013 at 9:45 PM, Cameron McInally > <cameron.mcinally at nyu.edu> wrote: >> Hey guys, >> >> My local

Hi Cameron, I'm planning to address this issue today. HTH, Alex On Mon, Nov 18, 2013 at 9:45 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > Hey guys, > > My local build is broken after: > >>r194813 | glider | 2013-11-15 08:13:01 -0500 (Fri, 15 Nov 2013) | 2 lines >> >>[ASan] Add the configure+make rules for building the ASan runtime for iOS

On Wed, Aug 29, 2018 at 3:13 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > On Wed, Aug 29, 2018 at 1:51 PM, Stephen Canon <scanon at apple.com> wrote: > >> On Aug 29, 2018, at 1:22 PM, Cameron McInally via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> >> FSUB(-0.0, NaN) = NaN >> FSUB(-0.0, -NaN) = NaN >>

Hey again, I have a nagging thought that my past comments may not have enough meat to them. So... On Mon, Apr 8, 2013 at 12:01 PM, Cameron McInally <cameron.mcinally at nyu.edu>wrote: ... > I was just writing Chandler about a similar implementation. With my > current understanding of the problem, my constant division will end up as > either a trap call or a load of an undefined

On Thu, Mar 1, 2012 at 5:30 PM, Cameron McInally <cameron.mcinally at nyu.edu>wrote: > Aligning the stack to 32 bytes when there are auto AVX vector variables >> present shouldn't necessarily break the x86-64 ABI, as long as smaller auto >> variables remain properly aligned. A similar approach was taken for i386 >> in GCC in order to support SSE vectors. >>

Hey Cameron, Sorry to reply this mail so late. Recently, I tried to understand what's the impact of the warning message (Warning: stand-alone `data16' prefix) And in binutils (gas/config/tc-i386.c), I found: if (!quiet_warnings) { ..... if (t->opcode_modifier.isprefix && t->opcode_modifier.ignoresize) { /* Warn them that a data or address

On May 23, 2013, at 10:37 AM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > In all fairness, I do not believe that ivdep is an ICC-specific pragma. There are many compilers that support ivdep and lots of legacy (and modern) codes that benefit from it. Seems silly, to me at least, to reinvent the wheel. Hi Cameron, The history of the idvep pragma is fascinating. I did not

This email did not appear to go through to the list. Resending... On Tue, Oct 23, 2012 at 11:43 AM, Cameron McInally <cameron.mcinally at nyu.edu > wrote: > On Mon, Oct 22, 2012 at 5:49 PM, Eric Christopher <echristo at gmail.com>wrote: > >> > In trunk, the frame pointer is always set up when an AVX register is >> used in >> > a function. This is done in

Well, yes, they are different operations. And, yes, this needs to be corrected. This wasn’t my point. It’s a given. I was getting at the _declared_ absence of side effects and what promises we make to anyone using the new fneg instruction. Is this a promise we want to make? From: Cameron McInally <cameron.mcinally at nyu.edu> Sent: Wednesday, September 26, 2018 2:30 PM To: Kevin Neal