On May 4, 2012, at 4:01 PM, Georg-Johann Lay wrote:
> Mike Stump schrieb:
>> On May 3, 2012, at 12:50 PM, Georg-Johann Lay wrote:
>>> It's hardly possible to write proper rtx_costs for SET:
>>> 1) What should be the cost of (const_int 1) if you don't see the machine 
>>> mode? Is it QI, is it HI, is it SI or whatever?
>> You can choose to see the complete expression in its entirety and
>> form the cost for it.
>> (set (reg:DI 1) (const_int 1))
> 
> Sorry, for the dumb question, but I still don't get it.

Ah, so, I answered the question, if there are no machine independent bugs, how 
would you do it...  Unstated in my email, is that I think that anybody (the 
machine independent code) that wants a better cost, needs to ask a more 
complete question of the port.  I view TARGET_RTX_COSTS as the answer for that 
question.

Stated differently, if an optimization pass has the information, a mode, a 
memory space, the containing expression, and those details matter, then you 
should merely submit bug fix requests for each instance to have them include 
those details into the question, as those details matter.  If you only get the 
question x = (const_int 1) outer = SET, and this comes from other than 
rtx_costs, than this would be such an instance where the machine independent 
code should be changed.  If it comes from rtx_costs in the recursive case, then 
previous to this question _was_ a question for the more complete case that the 
port ignored.

> TARGET_RTX_COSTS gets called with x = (const_int 1) and outer = SET
> for example. How do I get SET_DEST from that information?
> 
> I don't now if lower-subreg.s ever emits such cost requests, but several
> passes definitely do.

They are wrong (overly simplistic).

> There are machines with complex instructions sets like 4-operand
> OR and combined OR and SHIFT or similar. Instead of writing
> hundreds or thousands of lines in rtx_costs and XEXP TARGET_RTX_COSTS
> (effectively rewriting insn-recog.c) it would be straight forward
> to attach costs to insns and use recog + insn_attr to get the costs.
> 
> I tried that approach (write costs as insn attribute and use recog
> to get the costs) in a backend and it works smooth and really helped
> to keep the backend clean and maintainable.

Wow, cool.  I have costs, and I'd like a solution that feels cleaner to me, 
that certainly feels cleaner.  Calling recog seems scary to me...  the problem 
is that your supposed to get the costs of arbitrarily large code snippets, if 
you need multiple insns, you're supposed to add of all of them up.  Does this 
solution work when multiple instructions are needed?  If recog says it isn't a 
valid instruction, what do you do?  I shudder at the thought of replicating 
combine or reload...

>>> 3) Likewise, the costs of MEM are peeled of MEM and pass just the
>>> address without any information on the MEM like it's address space.
>>> Cost might highly depend on the address space involved.
>> Yes, that is why on my machine:
>> (set (mem) (reg))
>> has one set of costs, and
>> (set (reg) (mem))
> 
> What hook are we talking about?
> 
> TARGET_RTX_COSTS? (not called with outer=PATTERN)

This one...  I merely saw an instance where the machine independent code asked 
the right question...

Reply via email to