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/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding


On 04/27/2015 02:21 PM, Jiong Wang wrote:

Funny, I find myself wanting this transformation in both places :-)
Expansion time so that we generate efficient code from the start and
combine to catch those cases which are too complex to see at expansion,
but due to other optimizations become visible in the combiner.

Sadly, it's been fairly common practice for targets to define
double-word shift patterns which catch a variety of special cases.
Ports will have to choose between using those patterns and exploiting
your work.   I'd be tempted to generate a double-word shift by the given
constant and check its cost vs the single word shifts.

What happens if there's an overlap between t_low and low?  Won't the
lshift clobber low and thus we get the right value for the rshift in
that case?

Jeff,

   Sorry, I can't understand the meaning of "overlap between t_low and low",
   assume "right" in "right value" means the opposite of "left" not
   "correct".

   So what you mean is t_low and low share the same pseudo regiser?
My concern is sharing the same pseudo or memory location. But thinking more about it, the shifted value has to have range information, so it must have been an SSA_NAME, right? If so, then it can't overlap with the destination, so this is a non-issue. Sorry for the confusion.


Note that expand_variable_shift may not honor your request for putting
the result in the TARGET target parameter you pass in.

Thanks, agree, it's better to add those extra move.

I noticed the comments at the start of the function:

   "Store the result in the rtx TARGET, if that is convenient."

Although I still don't understand in which case it's inconveninent.
I've never liked the model of storing into TARGET when it's convenient. Because storing into TARGET is totally optional, it means the callers have to check if the value was stored into TARGET or not.

Sadly that model has been in the expanders as long as I can remember.

So I think this can go forward once we resolve the case where expand_variable_shift returns its value in something other than the passed in target.

Jeff


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