[PATCH] [4.2/4.1] PR/32004, tree-ssa caused in/out asm constraints to often need reloads

[Paolo Bonzini]

This patch is the official submission of the 4.1/4.2 version of my patch 
to fix PR32004.  The PR, an ice-on-valid caused by in/out asm 
constraints, is similar to PR21291 in spirit: in fact, the PR21291 test 
case did fail on 4.3 before my patch; on 4.1/4.2 instead a different 
test case is necessary, which was not reported by a user.

The patch is structured as a separate pass for simplicity (it is easier 
to read the code) and to turn it off on functions where it cannot have 
any effect.

The bulk of the backported patch is identical to the original, the only 
exception being the updating of dataflow.  On 4.3 the new df API is 
used, while on 4.1/4.2 I use update_life_info_in_dirty_blocks.

UPDATE_LIFE_GLOBAL_RM_NOTES and PROP_DEATH_NOTES are probably overkill 
but I used them for conservativeness in order to make sure dataflow info 
is valid.  Unfortunately, my original backport missed PROP_REG_INFO, 
which is an important item as local and global register allocation are 
the primary users of this information and (by design) no other pass runs 
between the new pass and the register allocator.

Honestly, it's not any kind of latent bug.  It was my mistake, and all I 
can say is that the new dataflow spoiled me. :-)  The way flow.c worked 
(it required each pass to update what it changed) is the exact opposite 
of the mindset of df-branch (each pass specifies the information it 
needs).  This is why we need conservativeness in calling 
update_life_info_in_dirty_blocks; the patch I attach is as conservative 
as it can be.

The patch is already there on 4.1 and 4.2, together with the fix to 
include PROP_REG_INFO.  The question is whether to leave it.

Pros:
- PR32004 is P1 at least according to the RM

Cons:
- the pass cannot be turned off with a command line flag

I won't put the simplicity (apparent or real) of the fix among the pros 
or cons: the problem I encountered meant that apparently it wasn't that 
simple, but I must say that the fix is a witness of how stupid is the 
cause of the failure.

Eric, who is an RTL maintainer, has already said that he opposes the fix 
to go on the 4.1 branch.

Are there any middle-end/global maintainers who are in favor, possibly 
two?  And equally, are there any other maintainers who agree with Eric?

Paolo