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: [PATCH] Exploiting dual mode operation, implementation.


> I can't open that .zip file, my unzip claims that the zip file is
> corrupted.  Is it a .tar.gz file???
I've resent the patch without the zip file and it finally reached 
the mailing list :-)
The testcases are simply attached to it.

> What about compile time and code size?
I'll check this further but for now I can say that there is almost 
no change in the code size. About the compile time, I expect it to 
be quite long since this optimization build a df object, runs 
combine on part of the code and reduced version of the gcse.

> First of all, I think you should submit the simplify_binary_operation_1
> and the combine_simplify_rtx parts as a separate patch.   It looks OK
> (to me at least ;-), it can probably go in by itself while people are
> discussing this pass.  Just ping Roger Sayle ;-)
The reason I didn't send it as a separate patch is that these 
simplifications are related to this patch. 
I didn't find the patterns that they are simplifying in the rtl without
enabling the see optimization (At least on PowerPC).
Do you still think that they should be submitted as a separate patch?

> have to interface with so many other parts of GCC...  I'm impressed by
> what you have done in see_try_combine and combine_instructions_chain.
> I'm sure smarter people than me can look at that and give an opinion...
Who should I ping about it ?

> Have you considered splitting up the pass in two passes: a pass before
> combine to add the extra sign-extends, and a post-combine pass to put
> the sign-extend insns in the right place using LCM?
The reason I didn't do it is that this way I need to pass information 
between passes, not through the rtl.
In the prepare for combine phase, I save the positions of the extra ses,
and I use this information during the combine phase when I transform the
pattern of the combined/uncombined insns according to the successfulness 
of the combining process.
If I'll just run combine as it is, I'll have to know, in the post 
combine phase where are the insns that were combined with se in order 
to prepare them for the PRE phase.
Another reason is that this way the optimization stands on her own 
completely and could be passed to different time during compilation 
easily. If I split it, it will depended on the combine passes.

> I guess it makes some sense to move stuff out of web.c and make the
> webizer available to other passes.  But in this case we should IMHO:
> - move things like web_entry to df.h because you're going to
>   need the df module anyway if you want to use the webizer.
>   We should not stuff yet more things into rtl.h...
> - export it as a complete pass that returns a set of webs with
>   some auxilary information (like your web_extra_flag_update_fn
>   provides).  Exposing unionfind_root/union_defs/etc. is ugly.
I guess that you are right.

> In addition, PRE doesn't handle PARALLELs, but I think that the part
> of the pass before combine, where you insert sign-extends, may add
> PARALLELs on e.g. x86.
Why should this happen? I'm just emitting a simple instruction before 
another instruction. If this realy happens, I believe that the PRE 
won't be the only problem.

> I also don't understand why you only want to apply PRE to insns
> created by the see pass itself (in see.c:want_to_gcse_p_se):
>
>   /* The sign extension insn wants_to_gcse_p only if it was created by
>      the se optimization.  */
>
> It seems to me that after combining it can be difficult to tell which
> sign-extends were created by the see pass, and you're skipping over
> all the other ones.  Why not just handle all of them if you're going
> to do it this way?
As I wrote above, I save the location of the ses that I generate before 
combine and use this information after it. This is how I don't skip 
them. This optimization optimizes only se that are in relevant webs, 
other ses in the code are not relevant at this point. The best 
placement for them should have already happen in the regular gcse pass.

> Batch of comments on see.c:
I accept all of your comments about this. I'll fix this. 

Thanks,
Leehod.


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