Displaying 5 results from an estimated 5 matches for "lhsknownzero".
Did you mean:
rhsknownzero
2011 Mar 08
0
[LLVMdev] First Patch
...g the
> // sign bit) the ripple may go up to and fill the zero, but won't change the
> // sign. For example, (X & ~4) + 1.
> -
> - // TODO: Implement.
> -
> +
> + unsigned width = LHS->getType()->getScalarSizeInBits();
> + APInt mask(width, -1, true), LHSKnownZero(width, 0), LHSKnownOne(width, 0),
> + RHSKnownZero(width, 0), RHSKnownOne(width, 0);
> +
> + ComputeMaskedBits(LHS, mask, LHSKnownZero, LHSKnownOne);
> + ComputeMaskedBits(RHS, mask, RHSKnownZero, RHSKnownOne);
> +
> + if (RippleBucketExists(LHSKnownZero, LHSKnownOne, RHSKno...
2011 Mar 08
2
[LLVMdev] First Patch
Hi!
I've attached a patch which takes care of the issues mentioned (and adds
two tests).
--
Sanjoy Das
http://playingwithpointers.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ripple-bucket.diff
Type: text/x-diff
Size: 3318 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110308/0814e3e8/attachment.diff>
2011 Mar 06
0
[LLVMdev] First Patch
...e LHS and
RHS are required to be equal for instructions like add. Just delete
this line.
> + APInt mask(width, 0), zeroes(width, 0), ones(width, 0);
These shadow (have the same name as) the ones before. It's better to
reuse the mask and rename the other two. The earlier ones should be
LHSKnownZero and LHSKnownOne and these should be RHSKnownZero and
RHSKnownOne. This is more consistent with the way they're named
elsewhere in LLVM.
> + mask.clearAllBits();
This is redundant here because it's already been initialized to zero
in the constructor. If you'd reuse the old mask...
2011 Mar 06
1
[LLVMdev] First Patch
Hi all!
I've been tinkering with LLVM's code-base for a few days, hoping to
start on one of the ideas mentioned in the "Open Projects" page (I was
told 'Improving the current system'/'Miscellaneous Improvements'/5 would
be a good start).
While I was at it, I also took a stab at finishing up one of the TODOs.
I've attached the patch for review.
--
2011 Mar 02
3
[LLVMdev] live variable analysis
Hi
As I understand live variable analysis will set the def/kill
properties of operands. In that case, is it still needed to set the
kill flags when possible during lowering?
thanks
dz