This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: expand and truncate and 387
- To: Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>
- Subject: Re: expand and truncate and 387
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Fri, 30 Oct 1998 00:29:14 -0700
- cc: egcs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <19981027145404.34050@atrey.karlin.mff.cuni.cz>you write:
> I am just looking at expand and truncate patterns. Since i387 holds all
> data in same registers and form, they are not required in reg-to-reg cases.
Which expand and truncate patterns? Please try to be precise, use the
names in the MD file if necessary.
If the values in the registers do not change due to a truncate or extension,
then those patterns should be changed to not emit any real instruction for
those operations.
We need to keep the patterns in the insn chain though.
> Because they are extremly slow (done by writing to memory and reading back)
> it is significant to avoid them
So, my question is why are we doing anything for them to begin with.
Can someone else that knows something abou the x86 confirm Jan's assertions?
What is he talking about? Don't we have to worry about rounding and truncation
when changing modes?
> I386.md partially handles this by patterns for each operation with first
> extend, second extend and both extended.
I'm sorry, I have no idea what you are talking about.
> I am not sure whether eliminating truncate in all cases is corret, but at
> least it is good -ffast-math or -mno-ieee-fp candidate.
I disagree. We don't want to go overboard with either option since all that
will do is make them useless.
Right now, those options control domain checks for things like sqrt and basically
enable some optimizations that are not safe in the presense of a NaN.
jeff