On Fri, Mar 28, 2014 at 8:48 AM, Saswat Padhi <saswat.sou...@gmail.com> wrote:
>
> I am Saswat Padhi, a final year undergraduate at IIT Bombay, India.
> With help from the GCC Resource Center here, I am currently investing
> possible improvements to GCC Machine Descriptions, with a goal of
> making them concise and composable.
>
> One of the improvements we were looking at is, reducing the C code
> fragments within the define_expand constructs in the machine
> descriptions. In some of the define_expands we observed that the C
> code fragments implement the same checks which can equivalently be
> achieved through the use of constraints. So, we thought that
> introducing constraints-validation at the expander level could be
> useful. An example of change we are proposing, is illustrated below:
>
> (define_expand "movsi"
> [(set (match_operand:SI 0 "nonimmediate_operand" "")
> (match_operand:SI 1 "general_operand" "")
> )]
> ""
> { if(GET_CODE(operands[0])==MEM && GET_CODE(operands[1])!=REG)
> { if(can_create_pseudo_p())
> { operands[1]=force_reg(SImode,operands[1]); }
> }})
>
> With the expander handling the constraints, the above define_expand
> can be written as:
>
> (define_expand "movsi"
> [(set (match_operand:SI 0 "nonimmediate_operand" "=r,m,r,r")
> (match_operand:SI 1 "general_operand" "r,r,i,m")
> )]
> ""
> )
>
> This concise define_expand expression would achieve the desired effect
> because when the first operand matches the second constraint
> alternative [m], the second operand would be force_reg into the second
> alternative [r]. All other cases are also explicitly mentioned as
> alternative constraints.
>
> As a first step towards this, I prepared this report
> (https://docs.google.com/document/d/1Yb5b3-r4YfxEL0omvAqqGFGIYLLeMenn-EHQvSHgKUw/edit)
> which is a survey of the define_expand expressions in i386 and MIPS
> machine descriptions. But as the report explains, the results of the
> survey do not appear in our favor. We see very few define_expands
> where we can actually replace some parts of the C code by introducing
> constraint validation in the expander.
>
> I seek feedback from the community regarding:
> 1. Is the idea is worth pursuing? In other words, would we be able to
> reduce significant amount of C code from the GCC MDs by introducing
> constraint validation at expander?
>
> 2. If answer to (1) is yes, do the parameters mentioned in the report
> make sense? We use 3 parameters to estimate whether we would be able
> to simplify a define_expand by removing at least a part of the C code.
>
> 3. If the answer to (2) is yes, why don't we see any gain in i386 and
> MIPS MDs? Then are there other cases where the gain would be
> significant?
>
> Thank you in advance for your time and help :-)Your result matches my intuition, which is that it wouldn't help much. For simple cases where contraints can carry the load, a named pattern can simply be a define_insn. For complex cases, constraints can not carry the load. We are left with a bit of a middle-ground, where constraints can help but there is still general work to be done in the define_expand body. I don't think that middle ground is very large. Ian
