This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] RTL docs update
On 7/4/07, Richard Sandiford <richard@codesourcery.com> wrote:
""Seongbae Park (박성배, 朴成培)"" <seongbae.park@gmail.com> writes:
> On 7/4/07, Seongbae Park (박성배, 朴成培) <seongbae.park@gmail.com> wrote:
>> So, in summary (apology if the table formatting doesn't survive):
>>
>> as insn within parallel
>> within non-parallel rtx
>> UNSPEC not deletable not deletable deletable
>> USE not deletable deletable deletable
>> CLOBBER not deletable deletable deletable
That's my understanding. (Pedantically, CLOBBERs as insns can
be deleted sometimes, but I realise you were simplifying for the
purposes of the table.)
>> My main gripe is that USE and UNSPEC are similar enough that the
>> distinction is confusing, and especially USE/CLOBBER being deletable
>> or not depending on whether it appears as insn or in parallel.
Well, I agree that the USE/CLOBBER situation is not nice, but that's
really because of the use of USE and CLOBBER as fancy dataflow markers.
I think the use of USE and CLOBBER in real insns is fairly intuitive.
So...
I think now I understand your position better - which isn't that
different from mine.
My issue with the current situation is that
USE and CLOBBER, when they appear at the INSN level,
we need to treat them as having unknown side-effect
that the compiler doesn't know about, hence we can not delete them,
whereas when they appear inside PARALLEL or other rtx,
they don't have any side-effect other than the direct influence
on its operand (USE using the operand, CLOBBER overwriting the operand
with some unknown value). [UNSPEC is similarly context-dependent,
except it is treated as having side effect even in PARALLEL].
I wanted to eliminate this context-dependent interpretation
(for USE and UNSPEC) by changing the definition of USE to have side-effect
and UNSPEC to have no side-effect *regardless of where they appear*.
However, the existing use of UNSPEC won't really allow us to do this
so we will have to continue this context dependent interpretation.
>> Hence my proposal was to distinguish between those two by whether
>> there's unknown effect to the runtime state (USE) or not (UNSPEC).
>> However, it looks like this will be a lot of work with small benefit,
>> so I'll drop the FIXME part, and update the comment on USE.
...it would be great if the df infrastructure could bring about the end
of USE and CLOBBER dataflow INSNs. INSN_P really would then mean what
it implies. And I think that's the more natural FIXME, not the
USE/UNSPEC thing. In real insns, USE and UNSPEC really do serve
two different purposes.
I'll look into eliminating insn-level USE and CLOBBER.
> Attached is the patch with the update.
> Presumably this just reflects the current status and nothing more.
> ChangeLog:
>
> 2007-07-03 Seongbae Park <seongbae.park@gmail.com>
>
> * rtl.def (UNSPEC): Drop FIXME.
> (USE): More comments.
FWIW (having griped so much), this looks good to me.
Thanks for your feedback.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";