Displaying 6 results from an estimated 6 matches for "calculationbits".
2009 Oct 13
1
[LLVMdev] 65bit integer math
...arEvolution.cpp.
Here's the big hack we put in, which is just the code that used to be there
in 2.3:
// We need at least W + T bits for the multiplication step
// FIXME: A temporary hack; we round up the bitwidths
// to the nearest power of 2 to be nice to the code generator.
unsigned CalculationBits = 1U << Log2_32_Ceil(W + T);
// Cray: Truncate to 64 bits. It's what we did with LLVM 2.3 and
// while it can create miscompilations in some cases if the
// computation happens to overflow, it's no worse than what we did
// before.
if (CalculationBits > 64) {
//retu...
2009 Feb 26
2
[LLVMdev] SCEVCouldNotCompute
...re:
// FIXME: Temporary hack to avoid generating integers that are too wide.
// Although, it's not completely clear how to determine how much
// widening is safe; for example, on X86, we can't really widen
// beyond 64 because we need to be able to do multiplication
// that's CalculationBits wide, but on X86-64, we can safely widen up to
// 128 bits.
if (CalculationBits > 64)
return new SCEVCouldNotCompute();
As an experiment I applied revision 62958 which gets rid of the fixme.
Codegen then asserts that it doesn't know how to do i128 arithmetic (on
x86-64). I tried...
2009 Feb 27
0
[LLVMdev] SCEVCouldNotCompute
...porary hack to avoid generating integers that are too wide.
> // Although, it's not completely clear how to determine how much
> // widening is safe; for example, on X86, we can't really widen
> // beyond 64 because we need to be able to do multiplication
> // that's CalculationBits wide, but on X86-64, we can safely widen up to
> // 128 bits.
> if (CalculationBits > 64)
> return new SCEVCouldNotCompute();
>
> As an experiment I applied revision 62958 which gets rid of the fixme.
> Codegen then asserts that it doesn't know how to do i128 ari...
2009 Feb 28
1
[LLVMdev] SCEVCouldNotCompute
...avoid generating integers that are too
> > wide. // Although, it's not completely clear how to determine how much //
> > widening is safe; for example, on X86, we can't really widen // beyond 64
> > because we need to be able to do multiplication
> > // that's CalculationBits wide, but on X86-64, we can safely widen up
> > to // 128 bits.
> > if (CalculationBits > 64)
> > return new SCEVCouldNotCompute();
> >
> > As an experiment I applied revision 62958 which gets rid of the fixme.
> > Codegen then asserts that it doesn'...
2009 Oct 13
0
[LLVMdev] 65bit integer math
On Mon, Oct 12, 2009 at 6:15 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> I have a test case(attached as fc_long.ll) that when run through the
> optimizer produces 65bit integer math(fc_long-opt.ll).
>
>
>
> Now I understand that llvm can have any length integer, but I consider
> turning a 64bit mul into multiple 65 bit instructions to be a ‘bad’
>
2009 Oct 13
4
[LLVMdev] 65bit integer math
I have a test case(attached as fc_long.ll) that when run through the
optimizer produces 65bit integer math(fc_long-opt.ll).
Now I understand that llvm can have any length integer, but I consider
turning a 64bit mul into multiple 65 bit instructions to be a 'bad'
optimization. This eventually expands to a 128bit multiply
call(__multi3) which I have absolutely no interest in supporting.