Jeff Law <jeffreya...@gmail.com> writes: > On 9/28/22 09:04, Richard Sandiford wrote: >> Tamar Christina <tamar.christ...@arm.com> writes: >>>> Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh. >>> But then I'd still need to change the expansion code. I suppose this could >>> prevent the issue with changes to code on other targets. >>> >>>>>> We have undocumented addcc, negcc, etc. patterns, should we have aandcc >>> pattern for this indicating support for andcc + jump as opposedto cmpcc + >>> jump? >>>>> This could work yeah. I didn't know these existed. >>>> Ah, so they are conditional add, not add setting CC, so andcc wouldn't >>>> be appropriate. >>>> So I'm not sure how we'd handle such situation - maybe looking at >>>> REG_DECL and recognizing a _Bool PARM_DECL is OK? >>> I have a slight suspicion that Richard Sandiford would likely reject this >>> though.. >> Good guess :-P We shouldn't rely on something like that for correctness. >> >> Would it help if we promoted the test-and-branch instructions to optabs, >> alongside cbranch? The jump expanders could then target it directly. >> >> IMO that'd be a reasonable thing to do if it does help. It's a relatively >> common operation, especially on CISCy targets. > > But don't we represent these single bit tests using zero_extract as the > condition of the branch? I guess if we can generate them directly > rather than waiting for combine to deduce that we're dealing with a > single bit test and constructing the zero_extract form would be an > improvement and might help aarch at the same time.
Do you mean that the promote_mode stuff should use ext(z)v rather than zero_extend to promote a bool, where available? If so, I agree that might help. But it sounds like it would have downsides too. Currently a bool memory can be zero-extended on the fly using a load, but if we used the zero_extract form instead, we'd have to extract the bit after the load. And (as an alternative) choosing different behaviour based on whether expand sees a REG or a MEM sounds like it could still cause problems, since REGs could be replaced by MEMs (or vice versa) later in the RTL passes. ISTM that the original patch was inserting an extra operation in the branch expansion in order to target a specific instruction. Targeting the instruction in expand seems good, but IMO we should do it directly, based on knowledge of whether the instruction actually exists. Thanks, Richard
