https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561

            Bug ID: 78561
           Summary: Constant pool size (offset) can become stale where
                    constant pool entires become unused
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jgreenhalgh at gcc dot gnu.org
  Target Milestone: ---

This bug report is mostly from inspection, but the effects of this issue can be
seen with this testcase on AArch64 (See also PR70120 for why we need the size
of the constant pool to be correct).

  int
  main (__fp16 x)
  {
    __fp16 a = 6.5504e4;
    return (x <= a);
  }

gcc foo.c -O3 -mcmodel=tiny -g

/tmp/ccwJITmo.s: Assembler messages:
/tmp/ccwJITmo.s: Error: unaligned opcodes detected in executable segment

In this test case, a call to force_const_mem in ira adds a new 32-bit constant
in the constant pool, but ultimately doesn't use it. That means that when we
sweep patterns looking for which constant pool entries to emit, we don't mark
the unused pattern created by ira, and it doesn't get emitted. But, that leaves
us with inconsistent information between the offset we think we've got, and
what we've actually emitted.

Presumably IRA isn't the only pass at fault here. Anything which eliminates a
reference to a constant pool entry can cause the constant pool offset
information to become stale, as it is only updated when inserting entries to
the constant pool, not when we decide those entries are actually used.

Maybe force_const_mem shouldn't be updating the offset information at all, and
we should only update that as we make the sweep in mark_constant_pool looking
for live pool entries? I guess the trouble there is that we don't record the
mode of the mem in the constant_descriptor_rtx - but if we were to do that it
looks like we might be able to defer calculating offset until when we actually
emit the pool. rs6000 might need some changes, but a better interface for their
uses of get_pool_size looks like it would be "pool_empty_p" anyway.

I'm not sure of this code though, so I don't know if that would make for a
clean design.

Reply via email to