This is the mail archive of the
mailing list for the GCC project.
Re: [Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding
- From: Jeff Law <law at redhat dot com>
- To: Jiong Wang <jiong dot wang at arm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 28 Apr 2015 21:50:01 -0600
- Subject: Re: [Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding
- Authentication-results: sourceware.org; auth=none
- References: <n99sic0uyf2 dot fsf at arm dot com> <5539A922 dot 7060708 at redhat dot com> <n99pp6pwaob dot fsf at arm dot com>
On 04/27/2015 02:21 PM, Jiong Wang wrote:
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.
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
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
So what you mean is t_low and low share the same pseudo regiser?
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.
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.
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.