Nick Lewycky wrote:
>> After your question, I have realized that 32 bits for the divisor may be
>> too much... Using "only" 16 bits would allow us to handle AddRecs up to
>> length 8. If you agree 16 is a safe bitwidth, I'll change it. However,
>> the maximum operation you ask about will still be n
Wojciech Matyjewicz wrote:
> Nick Lewycky wrote:
>> Just one question,
>>
>> + const IntegerType *ExTy = IntegerType::get(std::max(DividendBits, 32U));
>>
>> why the max of DividendBits and 32? If for whatever reason we think we
>> need only 16 bits for the computation, why expand it to 32?
>
>
Nick Lewycky wrote:
>
> Just one question,
>
> + const IntegerType *ExTy = IntegerType::get(std::max(DividendBits, 32U));
>
> why the max of DividendBits and 32? If for whatever reason we think we
> need only 16 bits for the computation, why expand it to 32?
We compute the divisor of the BC f
Chris Lattner wrote:
> On Feb 9, 2008, at 9:26 AM, Wojciech Matyjewicz wrote:
>
>> Hi,
>>
>> I've attached an updated version of the patch. It is ready for using
>> support for APInts in the code generator, but currently it doesn't
>> rely
>> on this feature. I've added a hack that rounds up the
Chris Lattner wrote:
>
> The patch looks good to me. Nicholas, can you please review it also?
> If Nicholas likes it, please commit,
IIRC, Nicholas reviewed the previous version. Nick, the only difference
is the hack to round the necessary bitwitdh up to 32 or 64 in the
beginning of BinomialC
On Feb 9, 2008, at 9:26 AM, Wojciech Matyjewicz wrote:
> Hi,
>
> I've attached an updated version of the patch. It is ready for using
> support for APInts in the code generator, but currently it doesn't
> rely
> on this feature. I've added a hack that rounds up the computation
> bitwidth to pow
Small correction:
> (only these bitwidths are allowed: 1, 2, ..., 64).
Should be: 32, 64.
-Wojtek
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Hi,
I've attached an updated version of the patch. It is ready for using
support for APInts in the code generator, but currently it doesn't rely
on this feature. I've added a hack that rounds up the computation
bitwidth to power of 2 (only these bitwidths are allowed: 1, 2, ...,
64). Hack is visib
On Jan 15, 2008, at 11:29 PM, Wojciech Matyjewicz wrote:
> Chris Lattner wrote:
>> I think we should wait to address this after LLVM 2.2 branches. That
>> said, the short-term fix is to round up to the next power of two
>> (e.g.
>> 32 or 64 bits) and disable this transformation when that size
Chris Lattner wrote:
> I think we should wait to address this after LLVM 2.2 branches. That
> said, the short-term fix is to round up to the next power of two (e.g.
> 32 or 64 bits) and disable this transformation when that size is not a
> "normal" llvm size (8, 16, 32, 64).
>
> Hopefully l
On Jan 15, 2008, at 1:36 PM, Wojciech Matyjewicz wrote:
> The attached patch should fix the aforementioned bug. It passes
> DejaGnu
> testsuite. Nick also checked that it passes llvm-test and llvm-gcc
> bootstrap (thanks!).
Oooh cool!
>
> The patch:
> 1) changes SCEVSDivExpr into SCEVUDivExpr
11 matches
Mail list logo
