similar to: [LLVMdev] Simple question on sign

how does llvm decide when to use unsigned instructions then? such as unsigned adds and loads? I'm trying to describe some multiply shift ops and getting a bit stuck differentiating between signed and unsigned. sam Eli Friedman-2 wrote: > > On Wed, Feb 22, 2012 at 4:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > On Wed, Feb 22, 2012 at 4:28 PM, Ryan Taylor <ryta1203

On Wed, Feb 22, 2012 at 4:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: On Wed, Feb 22, 2012 at 4:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > How do you determine if a shift is signed or not? > > ashr = always signed? Essentially, yes. > lshr = always unsigned? Essentially, yes. > shl = always signed? Signed left shift and unsigned left shift are both

Hi Sam, Whereas most languages track signedness on the variable/value level, LLVM IR takes a more machine-like approach of having the sign apply to the instruction rather than the value. It is therefore the frontend (or whatever is initially producing the LLVM IR) that should know whether an operation should be signed or unsigned. Hopefully that makes sense, Cheers, James -----Original

Thanks for the replies guys but I think I should have phrased my question better... looking at the Mips backend there are machine instructions that operate on signed and unsigned data, such as add and addu. And like Mips, I need to specify unsigned specific instructions, so how do these get chosen between if the LLVM IR does not carry type data? A very general point in the right direction is all i

Hi Sam, I am not a MIPS expert by any means, so YMMV, but: MIPS addu only differs to "add" in its (non)setting of the overflow flag. Because LLVM doesn't provide a way via the IR to access the overflow flag, a special notation isn't required in the IR to distinguish the two operations. Do you have another example? Cheers, James -----Original Message----- From:

Hi James, So does this mean if the instruction could set the overflow flag, the instruction should not have [(set ... )] in it's pattern, i see this is the difference in instruction description for the mips case. I'm wondering how llvm knows when to use certain compare instructions such as SETNE or SETUNE? And for sign or zero extending loads? I can see the PatFrags described and the

On 2018-08-22 11:32, John McCall wrote: > >> On Aug 22, 2018, at 4:38 AM, Bevin Hansson <bevin.hansson at ericsson.com> wrote: >> >> >> >> On 2018-08-22 05:56, John McCall via llvm-dev wrote: >>>> On Aug 21, 2018, at 6:20 PM, Leonard Chan <leonardchan at google.com> wrote: >>>> If we were to create a new type down the line, I

The documentation for SHL, LSHR, and ASHR is unclear. What is the result of shifting by the number of bits in the left operand. For example, <result> = shl i32 1, 32 <result> = ashr i32 1, 32 <result> = lshr i32 1, 32

I'm designing a language that supports array slicing. Does LLVM allows conversions between array pointers? For example, can I cast a pointer-to-array-of-5-ints to a pointer-to-array-of-3-ints? Can I get the address of the third element of an array-of-5-ints and convert it to a pointer-to-array-of-3-ints? Then again, I suppose a pointer-to-int would work just as well since LLVM

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,

Hello, We've just got a bug report from Mozilla folks about AddressSanitizer false positive with -O2. Turns out there is a conflict between load widening and AddressSanitizer. Simple reproducer: % cat load_widening.c && echo ========= && clang -O2 -c load_widening.c -flto && llvm-dis load_widening.o && cat load_widening.o.ll void init(char *); int foo() {

On Friday 18 July 2008 00:36, Nick Lewycky wrote: > David Greene wrote: > > Is my analysis correct? If so, is the PHI code the culprit (for not > > returning the min of the KnownZero bits) or is the Shl code the culprit > > (for not paying attention to the Mask passed in (it right shifts it)? > > I think your analysis is correct, and that Shl -- and many of the other

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.

Hello, >From [1], trunc does not seems to have a nsw/nuw attribute. Is it possible to have that? Or do we have that and it is not up-to-date? The definition would be: If the nuw keyword is present, the result value of the trunc is a poison value if the truncated high order bits are non-zero. If the nsw keyword is present, the result value of the trunc is a poison value if the truncated high

In tracking down an alignment bug, I think I found a problem in ComputeMaskedBits. But I am not very well versed in this area of LLVM and need some more eyes. This is in the 2.3 release, though it looks like the relevant pieces operate the same way in trunk. I have the following add recurrence: %r849 = select i1 %r848, i64 0, i64 %r847 ; <i64> [#uses=10] %r862 = shl i64 %r849, 3 ;

Ok, this makes sense. So, my follow up is then why, as in Mips, R600, etc... the bit value is checked in the tablegen. Seems that we should expect it to fit anyways if it still exists at this point? I'm having a hard time trying to get shl to take a PatLeaf for Imm instead of an ImmLeaf. On Mon, Apr 20, 2015 at 4:11 PM, David Majnemer <david.majnemer at gmail.com> wrote: > >

Chris Lattner wrote: > On Mon, 31 Mar 2008, Jon Sargeant wrote: >> I'm attaching another round of changes. Please verify that they are correct. > > Applied with edits: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060556.html > > I figured out what your patches don't apply. Something (your web browser, > editor, etc) is stripping

On 12/16/11 12:24 PM, Kostya Serebryany wrote: > Hello, > > We've just got a bug report from Mozilla folks about AddressSanitizer > false positive with -O2. > Turns out there is a conflict between load widening and AddressSanitizer. > > Simple reproducer: > % cat load_widening.c&& echo =========&& clang -O2 -c load_widening.c -flto&&

David Greene wrote: > Is my analysis correct? If so, is the PHI code the culprit (for not returning > the min of the KnownZero bits) or is the Shl code the culprit (for not paying > attention to the Mask passed in (it right shifts it)? I think your analysis is correct, and that Shl -- and many of the other operations (AShr, LShr, SExt, Add?, Call?) -- should be modified to always

For example: unsigned int x, y; void foo() { y = x >> 129; } Where int is a 16bit type, the .ll is producing only 'ret void' at O3. At O0 the .ll looks fine but then llc gets rid of it an simply returns. I'm just curious what the reasoning is for this? It isn't trying to set y to anything at all. Thanks. -------------- next part -------------- An HTML attachment was