This patch implements the approach I suggested in:
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00371.html
for fixing PR61360. To recap, the problem is with the use of "enabled" in
the i386.md pattern:
(define_insn "*float<SWI48:mode><MODEF:mode>2_sse"
[(set (match_operand:MODEF 0 "register_operand" "=f,x,x")
(float:MODEF
(match_operand:SWI48 1 "nonimmediate_operand" "m,r,m")))]
"SSE_FLOAT_MODE_P (<MODEF:MODE>mode) && TARGET_SSE_MATH"
"@
fild%Z1\t%1
%vcvtsi2<MODEF:ssemodesuffix><SWI48:rex64suffix>\t{%1, %d0|%d0, %1}
%vcvtsi2<MODEF:ssemodesuffix><SWI48:rex64suffix>\t{%1, %d0|%d0, %1}"
[(set_attr "type" "fmov,sseicvt,sseicvt")
(set_attr "prefix" "orig,maybe_vex,maybe_vex")
(set_attr "mode" "<MODEF:MODE>")
(set (attr "prefix_rex")
(if_then_else
(and (eq_attr "prefix" "maybe_vex")
(match_test "<SWI48:MODE>mode == DImode"))
(const_string "1")
(const_string "*")))
(set_attr "unit" "i387,*,*")
(set_attr "athlon_decode" "*,double,direct")
(set_attr "amdfam10_decode" "*,vector,double")
(set_attr "bdver1_decode" "*,double,direct")
(set_attr "fp_int_src" "true")
(set (attr "enabled")
(cond [(eq_attr "alternative" "0")
(symbol_ref "TARGET_MIX_SSE_I387
&& X87_ENABLE_FLOAT (<MODEF:MODE>mode,
<SWI48:MODE>mode)")
(eq_attr "alternative" "1")
/* ??? For sched1 we need constrain_operands to be able to
select an alternative. Leave this enabled before RA. */
(symbol_ref "TARGET_INTER_UNIT_CONVERSIONS
|| optimize_function_for_size_p (cfun)
|| !(reload_completed
|| reload_in_progress
|| lra_in_progress)")
]
(symbol_ref "true")))
])
The attribute was only really supposed to test properties of the currently-
selected target. It wasn't supposed to test function-specific size/speed
properties like the above pattern does.
So the idea was instead to add two new attributes that say whether
an alternative should be used when optimising for speed or size.
These attributes would just be strong optimisation hints; they wouldn't
be correctness properties in the way that "enabled" is. There are some
cases where we could end up with a size-only alternative in code
optimised for speed, or vice versa, but the idea would be to reduce
them as far as possible.
The main advantage of this approach is that we can take block-level
size/speed choices into account, rather than just looking at the
function-level choice.
Series tested on x86_64-linux-gnu.
Thanks,
Richard
