Re: RFC: Prefetch instruction support

[Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>]

> > 
> > (insn 92 28 30 (unspec_volatile[ 
> >             (plus:SI (plus:SI (mult:SI (reg/v:SI 26)
> >                         (const_int 4 [0x4]))
> >                     (reg:SI 29))
> >                 (const_int 128 [0x80]))
> >         ]  1) -1 (nil)
> >     (nil))
> 
> I would prefer new RTL codes to represent the prefetch:
> 
> (insn 92 28 30 (prefetch (mem:SI (plus:SI (plus:SI (mult:SI (reg/v:SI 26)
> 							    (const_int 4))
> 						   (reg:SI 29))
> 					  (const_int 128)))))

I can't have MEM code inside the expression to avoid scheduling conflicts and
some passes to think that address is valid.  It may point to the incorrect
location past the end of the array boundary.
Some passes similar to our current NULL pointer handling may take advantage
of that. Thats why I am using raw address operand inside unspec.

Richard is right about suggesting unspec at the place of unspec_volatile,
but what is the real advantage of having new PREFETCH code except for
need to add support for it to the rest of compiler?
If this is advantageous for some pass to understand what prefetch does,
I will happily implement this. But I am not aware of such pass at the moment.

Also note that there are multiple variants of PREFETCH. At least prefetch
for read and write acceses and then there are prefetch for single read
and prefetch for multiple reads (where the first don't read cache line, only
fills prefetch buffer) on Sparc architecture, so you will need to record
this somehow in prefetch opcode.

Honza