This is the mail archive of the 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: REVISED PATCH: adjust init_set_costs to account for call_used_regs (PR42505)


>> what about simply increasing the value of target_res_regs, instead?  After all,
>> target_res_regs is intended to acount for the scratch registers etc.
>> What about performance results on some mainstream architecture, say x86_64?
> I'm out of time for further experimentation and benchmarking; my manager 
> told me 2 weeks ago already that I'd spent enough time on this bug.  At 
> this point, I just want to get something checked in that prevents ivopts 
> from thinking it has 9 registers available when it only has 4 because of 
> the call in the loop.  If adding the additional register pressure 
> parameter is unacceptable without further experiments, I'll remove it 
> entirely.

while it is somewhat unfortunate, this seems to be the best course of action.
Fine-tuning parameters without sufficient testing is kind of pointless.

>> This needs to be a bit more careful -- you should exclude builtin calls that will
>> not be expanded to real function calls (e.g., builtin_prefetch),
> Is there code elsewhere in the compiler that knows which builtins are 
> guaranteed not to expand into a real function call? 

The code in tree-inline.c:estimate_num_insns for the GIMPLE_CALL case could be
factored to a new function and used for that,


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