Displaying 7 results from an estimated 7 matches for "lowermultidimrefs".
2005 Feb 22
1
[LLVMdev] Area for improvement
...but it can happen with any instructions (including the use of large integer
>> (or any FP) constants on RISC machines, addressing globals with PIC code,
>> handling extended/truncated operations (for RISC machines with a single
>> integer size), etc. Note that hacks like "LowerMultiDimRefs" and the sparc
>> Preselection pass sorta-kinda work around SOME of this,
>
> Actually, they are capable of working around much of this, and most such
> optimizations are actually quite architecture-independent, e.g.,
> LowerMultiDimRefs, which is a major optimization for...
2005 Feb 22
0
[LLVMdev] Area for improvement
...this, but it can happen with any instructions
> (including the use of large integer (or any FP) constants on RISC
> machines, addressing globals with PIC code, handling
> extended/truncated operations (for RISC machines with a single integer
> size), etc. Note that hacks like "LowerMultiDimRefs" and the sparc
> Preselection pass sorta-kinda work around SOME of this,
Actually, they are capable of working around much of this, and most
such optimizations are actually quite architecture-independent, e.g.,
LowerMultiDimRefs, which is a major optimization for array-intensive
langua...
2005 Feb 22
4
[LLVMdev] Area for improvement
...particular case of this,
but it can happen with any instructions (including the use of large
integer (or any FP) constants on RISC machines, addressing globals with
PIC code, handling extended/truncated operations (for RISC machines with a
single integer size), etc. Note that hacks like "LowerMultiDimRefs" and
the sparc Preselection pass sorta-kinda work around SOME of this, but they
really are just as bad as the problem: they solve some cases and make
other cases worse. The only way to make preselection or lowermultidimrefs
work is to duplication all of the knowledge of how the instructio...
2005 Feb 22
1
[LLVMdev] Area for improvement
On Feb 22, 2005, at 9:09 AM, Vikram S. Adve wrote:
>> The only way to make preselection or lowermultidimrefs work is to
>> duplication all of the knowledge of how the instruction selector will
>> select the code (e.g. the advice about allowing constant indices to
>> be grouped together).
>
> This is why you need a separate, low-level optimization framework -
> the kind you w...
2005 Feb 22
3
[LLVMdev] Area for improvement
Vikram S. Adve wrote:
>> The only way to make preselection or lowermultidimrefs work is to
>> duplication all of the knowledge of how the instruction selector will
>> select the code (e.g. the advice about allowing constant indices to
>> be grouped together).
>
>
> This is why you need a separate, low-level optimization framework -
> the kind...
2005 Feb 22
0
[LLVMdev] Area for improvement
I figured getelementptr exists as it does to facilitate data flow
analysis, but it does need to be broken down before instruction
selection. It's not just the missed optimization opportunities. It
also introduces a huge amount of complexity into instruction selection
as they deal with its complexity. It would also take care of many of
the FIXMEs in LoopStrengthReduce.
Vikram Adve
2005 Feb 22
3
[LLVMdev] Area for improvement
>
> Now the problem is obvious. A two dimensional array access is being
> performed by a single instruction. The arithmetic needed to address
> the element is implicit, and therefore inaccessible to optimizations.
> The redundant calculations can not be eliminated, nor can strength
> reduction be performed. getelementptr needs to be broken down into
> its constituent