This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] RTL docs update

On 7/4/07, Richard Sandiford <> wrote:
""Seongbae Park (박성배, 朴成培)"" <> writes:
> On 7/4/07, Seongbae Park (박성배, 朴成培) <> 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.

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. 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  <>
>         * 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,";

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]