search for: calculationbit

...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) { //ret...

...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 trie...

...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 ar...

...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'...

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’ >

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.