Displaying 20 results from an estimated 8000 matches similar to: "[LLVMdev] Does lli know how to interpret arithmetic overflow intrinsics?"
2011 May 05
0
[LLVMdev] Does lli know how to interpret arithmetic overflow intrinsics?
I understand that overflow behaviours can be different on different
hardware. But can we write .ll implementation of these overflow intrinsics,
e.g. assuming 0..255 as value range for unsigned i8 ?
- sanjiv
On Thu, May 5, 2011 at 11:18 AM, Sanjiv <llvmdev at gmail.com> wrote:
> Do we have a .ll test cases for arithmetic overflow intrinsics that lli can
> execute and report any
2016 Jul 19
3
X86ISelLowering: Promote 'add nsw' to a wider type
Hi Sanjay,
Some time ago you implemented a sext(add_nsw(x, C)) --> add(sext(x), C_sext) transformation in X86ISelLowering
https://reviews.llvm.org/D13757
Is there any reason why this transformation is limited to sexts and doesn’t support zexts?
Thanks,
Artur
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2016 Aug 08
2
X86ISelLowering: Promote 'add nsw' to a wider type
Hi Sanjay,
On 19 Jul 2016, at 18:54, Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>> wrote:
Hi Artur -
I don't think there's any reason to limit the transform to sexts only; that's just the case that was apparent in https://llvm.org/bugs/show_bug.cgi?id=20134 , so I limited it to that pattern.
It's probably worth noting that I'm
2016 Sep 29
2
IR canonicalization: select or bool math?
My gut tells me that Hal is right, and we should prefer zexts as long
as the select boils down to one instruction, but let me go against my
intuition and try to list two reasons why we should prefer selects:
* Folding operations into selects: it is trivial to transform
f(select X, Const0, Const1) to select X, f(Const0), f(Const1),
while doing that can be difficult for zexts.
define
2015 Apr 18
2
[LLVMdev] Does LLVM optimize rudimentary i16 -> i32 conversions
In my language there are a lot of i16 definitions, but almost all of the
time they are upgraded to i32 because my add operations only happen on i32.
So to be representative to my language definition, I have a lots of
Sext/Zext and Truncs pretty much every time I add or subtract.
As soon as I pass through InstCombine things look much nicer, all the
upcasts and downcasts go away, but my test cases
2015 Jun 10
3
[LLVMdev] Question about NoWrap flag for SCEVAddRecExpr
I am testing vectorization on the following test case:
float x[1024], y[1024];
void myloop1() {
for (long int k = 0; k < 512; k++) {
x[2*k] = x[2*k]+y[k];
}
}
Vectorization failed due to "unsafe dependent memory operation". I traced
the LoopAccessAnalysis.cpp and found the reason is the NoWrapFlag for
SCEVAddRecExpr is not set and consequently the
2015 Jun 11
4
[LLVMdev] Question about NoWrap flag for SCEVAddRecExpr
[+Arnold]
> On Jun 10, 2015, at 1:29 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
>
> [+CC Andy]
>
>> Can anyone familiar with ScalarRevolution tell me whether this is an
>> expected behavior or a bug?
>
> Assuming you're talking about 2*k, this is a bug. ScalarEvolution
> should be able to prove that {0,+,4} is <nsw> and
2015 Jan 29
2
[LLVMdev] RFC: Proposal for Poison Semantics
On 01/27/2015 09:38 PM, Sanjoy Das wrote:
>> if the definition of NUW is that zext-ing the result is equivalent to
>> zext-ing the inputs and doing the operation at a higher bitwidth (my
>> understanding), then %m and %n cannot hold those values, that would violate
>> the NUW flag.
> The problem to solve is adequately defining "cannot hold". In the
>
2015 Jan 28
2
[LLVMdev] RFC: Proposal for Poison Semantics
On Tue, Jan 27, 2015 at 7:23 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:
> Hi David,
>
> I spent some time thinking about poison semantics this way, but here
> is where I always get stuck:
>
> Consider the IR fragment
>
> %x = zext i32 %maybe_poison to i64
> %y = lshr i64 %x 32
> %ptr = gep %global, %y
> store 42 to %ptr
>
> If
2015 Jan 29
0
[LLVMdev] RFC: Proposal for Poison Semantics
> I don't think your example is actually problematic. The original program
> before your transformation *executed* undefined behavior in the form of '%x
> = add nuw i32 %m, %n' with "%m = %n = 2^32-1 (a.k.a INT_MAX)". If I
I was trying to show why the rule "signed overflow is undefined
behavior" is problematic w.r.t. hoisting arithmetic by repeating an
2016 Sep 28
4
IR canonicalization: select or bool math?
I have another round of questions about IR select canonicalizations. For
the purity of this quiz, please disregard prior knowledge of how this is
handled by instcombine or how this is lowered by your favorite target...of
course we'll fix it. :) Some answers in the links below if you do want to
know.
Which, if any, of these is canonical?
1. Is a zext simpler than a select?
a. define i32
2009 Nov 13
2
[LLVMdev] Proposal: intp type
On Nov 12, 2009, at 11:29 PM, John McCall wrote:
>> sext/zext/trunc are very nice for the optimizer, we should keep
>> them. It means that the optimizer doesn't have to check that the
>> input to a sext is bigger or smaller than the result, for example.
>> Code that cares (e.g. instcombine) really likes this.
>
> We could just say that code has undefined
2019 Sep 19
2
Interpreter and arithmetic overflow intrinsics
Hi all,
I am trying to run LLI on an optimized bitcode file in interpreted
mode, and I get the following error message:
LLVM ERROR: Code generator does not support intrinsic function
'llvm.usub.with.overflow.i32'!
As the error message indicates, this intrinsic is not supported
(lib/CodeGen/IntrinsicLowering.cpp). Is there any way that I can get
the interpreter to work across this
2017 Jul 01
8
[IR canonicalization] 6 ways to choose {-1,0,1}
I'm looking at the output of memcmp() expansion (D34904), and I noticed
that there are many ways to produce the common positive/zero/negative
comparison result in IR.
For the following 6 functionally equivalent C source functions, we produce
6 different versions of IR which leads to 6 different asm outputs for x86.
Which of these should we choose as canonical IR form?
1. Two selects
int
2011 Apr 13
2
[LLVMdev] signedess of operands
Hi,
As my target supports signed / unsigned interpretation of operands, I was a bit startled to find that the LLVM I/R does not express this info of the integer operands. I want to create an eg unsigned mul if the operands are unsigned, using an intrinsic.
I find that with -g, metadata is generated which seems to convey this information. Is it safe to base this type of transformation on the
2009 Nov 13
1
[LLVMdev] Proposal: intp type
John McCall wrote:
> I didn't realize that an identity zext was actually invalid IR. That
> seems like it probably causes more trouble than it's worth.
>
> Anyway, I suspect the question is whether you would rather break these
> invariants (which are probably not critical for most optimizations) or
> slowly accumulate duplicate code paths in every pass that looks at
2009 Nov 13
0
[LLVMdev] Proposal: intp type
Chris Lattner wrote:
> On Nov 12, 2009, at 11:29 PM, John McCall wrote:
>>> sext/zext/trunc are very nice for the optimizer, we should keep
>>> them. It means that the optimizer doesn't have to check that the
>>> input to a sext is bigger or smaller than the result, for example.
>>> Code that cares (e.g. instcombine) really likes this.
>>
2009 Jul 16
2
[LLVMdev] llvm.memcpy intrinsics.
clang generates llvm.memcpy.* intrinsics for our port.
Now we are linking a .bc version of the standard library. Do we have to
include a version of these intrinsics in the .bc librrary? If yes, do we
have some already written version?
Or do we have to leave them for llc to convert them in to memcpy and
then provide an binary version of lib with these functions ?
- Sanjiv
2015 Jun 11
2
[LLVMdev] Question about NoWrap flag for SCEVAddRecExpr
> On Jun 10, 2015, at 6:17 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
>
> I'm not sure if inbounds can be used to prove <nuw>. If an object
> %OBJ is allocated at address -1 then "gep inbounds %OBJ 1" is not
> poison, but the underlying computation unsigned-overflows.
I think that this should yield poison per langref because the signed
2016 Jan 05
3
TargetTransformInfo getOperationCost uses
Hi,
I'm trying to implement the TTI hooks for AMDGPU to avoid unrolling loops for operations with huge expansions (i.e. integer division).
The values that are ultimately reported by opt -cost-model -analyze (the actual cost model tests) seem to not matter for this. The huge cost I've assigned division doesn't prevent the loop from being unrolled, because it isn't actually