Displaying 12 results from an estimated 12 matches for "knownones".
Did you mean:
knownone
2016 May 03
3
Reasoning about known bits of the absolute value of a signed integer
I'm trying to reason about how to find certain bit positions of the absolute value of a given integer value. Specifically, I want to know the highest possibly set bit and lowest possibly set bit of the absolute value, in order to find the range between the two.
Note that I'm specifically trying to be as conservative as possible.
This is what I have so far:
If the sign bit of the
2018 Jun 12
2
One more No-alias case on Alias analysis
...== idx => 3 == 2*idx
and you've generalized this slightly to make this:
(odd number) == 2*idx
which makes sense. I think that we can go further looking at:
n == 2*idx
and, calling computeKnownBits on n and idx, then asking whether:
knownZeros(n) == (knownZeros(idx) << 1) | 1 and
knownOnes(n) == knownOnes(idx) << 1
(please note the comment in aliasSameBasePointerGEPs regarding avoiding
PR32314)
also, if we have more than one array access, we can have:
n - idx == m - idx
then we have:
n-m == 2*idx
and so we can check:
knownZeros(n-m) == (knownZeros(idx) << 1) | 1 an...
2011 Feb 10
1
[LLVMdev] PR9112
Hello,
This simple patch fixes PR9112:
Index: lib/Analysis/ValueTracking.cpp
===================================================================
--- lib/Analysis/ValueTracking.cpp (revision 125281)
+++ lib/Analysis/ValueTracking.cpp (working copy)
@@ -593,6 +593,8 @@
// Otherwise take the unions of the known bit sets of the operands,
// taking conservative care to avoid
2009 Jul 30
2
[LLVMdev] Vector logic regression in r73431
Hi all,
Hi Eli,
No, that appears to be something unrelated. I'm currently using revision
75246, while that patch only seems to apply to some later revision.
Anyway, I actually located the real bug. Right at the end of
InstCombiner::SimplifyDemandedUseBits, there's this piece of code:
// If the client is only demanding bits that we know, return the known
// constant.
if
2018 Jun 11
4
One more No-alias case on Alias analysis
Hello All,
I have met one may-alias case from llvm's alias analysis. The code
snippet is as following:
char buf[4];
void test (int idx) {
char *a = &buf[3 - idx];
char *b = &buf[idx];
*a = 1;
*b = 2;
}
I can see below output from alias set tracker for above code snippet.
Alias sets for function 'test':
Alias Set Tracker: 1 alias sets for 2 pointer values.
2009 Jul 30
0
[LLVMdev] Vector logic regression in r73431
On Thu, Jul 30, 2009 at 5:57 AM, Nicolas Capens<nicolas at capens.net> wrote:
> No, that appears to be something unrelated. I'm currently using revision
> 75246, while that patch only seems to apply to some later revision.
I don't see the connection... anyway, I can't easily help you with an
old revision.
> Anyway, I actually located the real bug. Right at the end of
2008 Nov 21
2
[LLVMdev] computeMaskedBitsforTargetNode
Can someone explain what this function is supposed to do? I've looked at
PowerPC, Sparc, etc.. and can't really figure out what I should be doing
here.
Thanks,
Micah Villmow
Systems Engineer
Advanced Technology & Performance
Advanced Micro Devices Inc.
4555 Great America Pkwy,
Santa Clara, CA. 95054
P: 408-572-6219
F: 408-572-6596
-------------- next part
2009 Jul 29
0
[LLVMdev] Vector logic regression in r73431
On Wed, Jul 29, 2009 at 3:45 AM, Nicolas Capens<nicolas at capens.net> wrote:
> So could anyone who knows the ins and outs of this code have a look at how
> to make it handle vectors correctly? Or if that’s not an option right now,
> please revert the broken optimizations. Note that there might be more things
> affected than visitAnd, visitOr and vistXor, I’ve only been able to
2009 Jul 29
3
[LLVMdev] Vector logic regression in r73431
Hi All,
I found a regression which triggers the asserts: "Binary operator types must
match!" and "Op types should be identical!". It's happening with a piece of
vector code, and the asserts happen because a logic operation is attempted
between a vector and a scalar (which is not present in the original code,
but created by InstCombine).
It's caused by revision
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote:
> Can you explain why you chose the approach of using a new pass?
> I pictured removing LegalizeDAG's type legalization code would
> mostly consist of finding all the places that use TLI.getTypeAction
> and just deleting code for handling its Expand and Promote. Are you
> anticipating something more
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On May 20, 2009, at 1:34 PM, Eli Friedman wrote:
> On Wed, May 20, 2009 at 1:19 PM, Eli Friedman
> <eli.friedman at gmail.com> wrote:
>
>> Per subject, this patch adding an additional pass to handle vector
>>
>> operations; the idea is that this allows removing the code from
>>
>> LegalizeDAG that handles illegal types, which should be a significant
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote:
>> Can you explain why you chose the approach of using a new pass?
>> I pictured removing LegalizeDAG's type legalization code would
>> mostly consist of finding all the places that use TLI.getTypeAction