Kenneth Zadeck - Re: Some thoughts and quetsions about the data flow infrastracture (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing 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]

Seongbae Park wrote:

On 2/13/07, Vladimir Makarov vmakarov@redhat.com wrote: ...

Seongbae, I am sorry I already wrote that is my last email on the thread. So I am answering you privately.

That's fine. Thanks for replying quickly.

To be honest, I thought about this infrastructure long ago. So I don't remeber details. And may be my ideas are wrong. But in brief, I don't like df_ref (insn, loc etc) representation. I thought about attaching def to reg/subreg (like reg attributes) and acessing to it through rtx only. To make some compromise between smaller data and speed access. Probably, I need to investigate it more. It is complicated that the register rtx is shared before the reload.

Ok. I think it sounds pretty reasonable - though it would certainly take more effort to implement, as it requires changes in rtx. Maybe we should hide df_ref completely so that we can later get rid of separate df_ref's and allow integrating it into rtx. I'll also think about it. Thanks for the idea.

Personally, I'm not (still) really familiar with RTL enough to try changing it.

I would love to be able to do this but there are some very deep (i.e. it is going to be a lot of work) issues that have to be addressed first.

  1. rtl has shared leaf nodes. There have been attempts to stamp this out, but until this really happens, this idea is doa.

  2. the style of changing rtl will have to change even more. People are used to just going in and doing a little trim here and a touch there. Having the refs hang off the leaves when people do this is more tricky than what we have now.

However, if the consensus of the community (i.e. a few brave volunteers come forward to attack this), I will be happy to help.

While you are at it, have a pointer from the insn to the df info for the insn rather than having to go thru the insn_uid and into an array.

As for solver, as I remember Danny took it from paper about full program analysis. It works well in extremely big cases but I am not sure it works better for the current average gcc data especially for small sets like hard register set which data flow should be dealing with after the reload. It probably needs more investigation too at least for me.

I don't quite understand this point. I think it's possible to come up with a df problem that uses any representation it wants, e.g. HARD_REG_SET. Which part of the solver you think would pessimize small sets case ? btw - i was not offended by the tone of this discussion. I am quite used to these things getting out of hand both quickly and for no apparent reason.

Kenny

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