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...
