Fix finding reg-sets of call insn in collect_fn_hard_reg_usage

Richard,

atm the moment, when processing a call in collect_fn_hard_reg_usage, we get the 
used regs from the callee, but forget to register the regs in the call insn 
itself (ouch).  This patch fixes this by introducing an extra IOR_HARD_REG_SET.

We also switch the order of find_all_hard_reg_sets and get_call_reg_set_usage. 
There's no point in doing find_all_hard_reg_sets on a call if 
get_call_reg_set_usage returns false.

OK for trunk if bootstrap and reg-test on x86_64 is ok ?

Thanks,
- Tom

On 06/19/2014 09:07 AM, Tom de Vries wrote:
> 
> 2014-06-19  Tom de Vries  <tom@codesourcery.com>
> 
> 	* final.c (collect_fn_hard_reg_usage): Add separate IOR_HARD_REG_SET for
> 	get_call_reg_set_usage.

Ok, as far as it goes, but...

It seems like there should be quite a bit of overlap with regs_ever_live here.
 How much of that previous computation can we leverage?

It appears that regs_ever_live includes any register mentioned explicitly, and
thus the only registers it doesn't contain are those killed by the callees.
That should be an easier scan than the rtl, since we have those already
collected in the cgraph.

Sorry I wasn't paying much attention earlier when this was first posted, when
questions like this may have been answered.


r~

On 06/19/2014 09:40 AM, Richard Henderson wrote:
> It appears that regs_ever_live includes any register mentioned explicitly, and
> thus the only registers it doesn't contain are those killed by the callees.
> That should be an easier scan than the rtl, since we have those already
> collected in the cgraph.

And I forgot to mention it might be worth while to notice simple recursion.
Avoid the early exit path if caller == callee, despite the caller-save info not
being valid.


r~

On 19-06-14 18:40, Richard Henderson wrote:
> On 06/19/2014 09:07 AM, Tom de Vries wrote:
>>
>> 2014-06-19  Tom de Vries  <tom@codesourcery.com>
>>
>> 	* final.c (collect_fn_hard_reg_usage): Add separate IOR_HARD_REG_SET for
>> 	get_call_reg_set_usage.
>
> Ok, as far as it goes, but...
>
> It seems like there should be quite a bit of overlap with regs_ever_live here.
>   How much of that previous computation can we leverage?
>
> It appears that regs_ever_live includes any register mentioned explicitly, and
> thus the only registers it doesn't contain are those killed by the callees.
> That should be an easier scan than the rtl, since we have those already
> collected in the cgraph.
>
> Sorry I wasn't paying much attention earlier when this was first posted, when
> questions like this may have been answered.
>

Richard,

At the moment, collect_fn_hard_reg_usage is run in pass_final, after final (), 
that is, after the final splitting of insns. The idea is that we use the most 
final representation available, to be on the safe side.

AFAIU, the regs_ever_live information is computed using the df infrastructure, 
which requires the cfg, which is available only until pass_free_cfg for all 
targets (more details in this discussion: 
https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01060.html ). I don't think 
regs_ever_live is guaranteed to be up to date afterwards.

So in order to known whether it's safe and optimal to use regs_ever_live 
instead, the question is whether the passes after pass_free_cfg (are allowed to) 
add or remove sets or clobbers of call_really_used_regs. I don't know the full 
answer there.

Eric, can you comment?

Thanks,
- Tom

> So in order to known whether it's safe and optimal to use regs_ever_live
> instead, the question is whether the passes after pass_free_cfg (are allowed
> to) add or remove sets or clobbers of call_really_used_regs. I don't know
> the full answer there.

pass_machine_reorg is run after pass_free_cfg and it can do pretty much what 
it wants so I'd think that the answer is yes.

On 07/02/14 02:32, Eric Botcazou wrote:
>> So in order to known whether it's safe and optimal to use regs_ever_live
>> instead, the question is whether the passes after pass_free_cfg (are allowed
>> to) add or remove sets or clobbers of call_really_used_regs. I don't know
>> the full answer there.
>
> pass_machine_reorg is run after pass_free_cfg and it can do pretty much what
> it wants so I'd think that the answer is yes.
Agreed -- until such time as we decide to place some limits on the 
machine dependent reorg pass.  Right now I think the only limit is the 
result of that pass must be valid RTL.  Pretty weak :(

Jeff