https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #45 from Bernd Edlinger <bernd.edlinger at hotmail dot de> --- (In reply to wilco from comment #44) > (In reply to Bernd Edlinger from comment #38) > > Created attachment 39939 [details] > > proposed patch, v2 > > > > > Unlike the previous patch, thumb1 stack usage stays at 1588 bytes, > > because thumb1 cannot split the adddi3 pattern, once it is emitted. > > We can split into a new pattern that contains adds/adc together. Splitting > should help Thumb-1 the most as it has just 3 allocatable DI mode > registers... But we need to split the adds and the adc into two separate pattern, then it can happen that the adc instruction's result is unused, and that propagates to the inputs. But since I read this comment in thumb1.md I have doubts: ;; Beware of splitting Thumb1 patterns that output multiple ;; assembly instructions, in particular instruction such as SBC and ;; ADC which consume flags. For example, in the pattern thumb_subdi3 ;; below, the output SUB implicitly sets the flags (assembled to SUBS) ;; and then the Carry flag is used by SBC to compute the correct ;; result. If we split thumb_subdi3 pattern into two separate RTL ;; insns (using define_insn_and_split), the scheduler might place ;; other RTL insns between SUB and SBC, possibly modifying the Carry ;; flag used by SBC. This might happen because most Thumb1 patterns ;; for flag-setting instructions do not have explicit RTL for setting ;; or clobbering the flags. Instead, they have the attribute "conds" ;; with value "set" or "clob". However, this attribute is not used to ;; identify dependencies and therefore the scheduler might reorder ;; these instruction. Currenly, this problem cannot happen because ;; there are no separate Thumb1 patterns for individual instruction ;; that consume flags (except conditional execution, which is treated ;; differently). In particular there is no Thumb1 armv6-m pattern for ;; sbc or adc. Disabling the adddi3 pattern worked with control flow instead of passing the Carry flag from thee adds to the adc pattern. In the sha512 test case that was still profitable, but I think that will not be the case in general. I can live with the state of thumb1 in the moment. I am more interested in early expansion of di patterns in vfp / avoid_neon_for_64bits and so on. Maybe if the user explicitly wants neon_for_64bits, so be it.
