This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Prefetch instruction support
On Wed, Apr 12, 2000 at 11:17:39AM +0200, Jan Hubicka wrote:
> > >
> > > (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.
--
Michael Meissner, Cygnus Solutions, a Red Hat company.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482