RFC: Prefetch instruction support

[Jan Hubicka]

> > > > (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.
> 
> I would imagine the scheduler will want to know about it eventually.  It is
> also helpful to those of who work on multiple machines to have a standard way
> of doing it.
OK.
Can you suggest the form of instruction to make it flexible enought to
handle the cases noted above? (prefetch/prefetchw and prefetches for single/
multiple accesses)

Maybe this can come as separate patch later. For now this is change to
single instruction pattern at i386.

Honza