This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/60749] New: combine is overly cautious when operating on volatile memory references
- From: "amylaar at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 03 Apr 2014 15:41:42 +0000
- Subject: [Bug rtl-optimization/60749] New: combine is overly cautious when operating on volatile memory references
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60749
Bug ID: 60749
Summary: combine is overly cautious when operating on volatile
memory references
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amylaar at gcc dot gnu.org
Blocks: 53938
Curtesy of volatile_ok / init_recog_no_volatile, combine will
reject any combination that involves a volatile memref in the combined
pattern.
In particular, if any narrow memory location is read on a
WORD_REGISTER_OPERATIONS target, the zero/sign extension can't be combined
with a memory read, even if a suitably extending memory load instruction is
available - unless that pattern gets specifically written to accept
volatile memrefs, shunning the standard memory_operand and
general_operand predicates.
combine already needs to do special checks to make sure it doesn't
slip up when handling such patterns (E.g. see PR51374), so what good
does init_recog_non_volatile do combine these days?
At the very least, I think we should allow combinations involving a single
memref with unchanged mode before and after combination - that woud cover
the zero and sign extending loads.