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