This is the mail archive of the gcc-patches@gcc.gnu.org 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: new sign/zero extension elimination pass


Paolo,

Paolo Bonzini wrote:
> > On 10/22/2010 10:30 AM, Eric Botcazou wrote:
>> >> If not, why does it not use
>> >> the DF framework instead of recomputing DU chains manually?
> >
> > Rather than on DU chains (which are a very expensive problem just
> > because of its asymptotic complexity, so it's better to use it only on
> > small regions such as loops), I'd be picky about usage of note_uses,
> > which can be very simply replaced by a loop over the DF_INSN_USES vector.
> >
> > Paolo

I just looked into using DF_INSN_USES, and I'm not sure that using that is a
good idea. There is a difference between using note_uses and DF_INSN_USES.

If there is an insn
...
(set
  (reg:SI 1)
  (plus:SI (reg:SI 2)
           (reg:SI 3)))
...

the note_uses helper function will be visited with the plus expression,
something that is used in the pass (see note_use in ee.c). Using DF_INSN_USES
will only yield (reg:SI 2) and (reg:SI 3), and does not provide the context in
which it is used.


Furthermore, I would like to know whether there is a problem with checking in
the pass into trunk in its current form. My understanding of the discussion up
until now is that the consensus is that the pass is useful, but not fully efficient.
I agree with the fact that it's possible to improve it, but I also think that
the runtime is negligible (it's an O(n) pass currently) and the benefit of
improving the pass will not be worth the effort. I will try to confirm this with
a profiling run on spec2000. If the profiling run confirms that the runtime is
negligible, is the pass (in principle) ok for trunk?
If so, I will sent out a new version with a few bug fixes that were missing in
the previous version.

Thanks,
- Tom


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