Re: [CFT] x64 SEH, test 2

[Olivier Hainque <hainque at adacore dot com>]

Richard Henderson wrote:
> I hadn't realized that you did it in the Ada front end.

 Some aspects of the triggers are Ada specific, I think. The central
 facility (make_aligning_type) resorts to a couple of gigi facilities
 but could probably be genericized.

 expand_expr used to know about what it does pretty intimately via
 is_aligning_offset. A while ago, we adjusted the way the field offset
 is constructed and used to _need_ to adjust is_aligning_offset
 accordingly (making it more general, commentary part of an old patch
 below). We were getting crashes otherwise IIRC.

 This need sort of went away with GCC 4 - no more crashes, testcases
 behaving properly etc. I haven't investigated wht in detail.
 
> I was thinking along the lines of adding an alignment test to the
> existing variable partitioning scheme in cfgexpand.c.  We'd then
> squash together all partitions that require alignment larger than
> we can provide with MAX_STACK_ALIGNMENT.  We'd then allocate this
> highly aligned partition with the alloca machinery, and set the
> DECL_RTL for all affected variables so that they point into the
> alloca block.
> 
> This scheme handles user data just fine, but does not handle any
> additional alignment required by the register allocator (i.e. 
> vector data spills) or by outgoing function parameters.
> 
> For the specific case of x64 windows, we are already guaranteed
> 16-byte stack alignment, and so there should be no extra alignment
> needed by either of the above.  (This assumes that AVX spills are
> performed with unaligned stores/loads, which is supposed to 
> perform well on cpus with that extension.)
> 
> However, the scheme does not require _any_ special target support,
> and so there are plenty of targets that ought to be able to benefit
> from being able to get highly aligned user data.

 Sounds like a fine plan indeed.

 One aspect that the gigi bits handle is allocators (ptr := new Bla;),
 working fine as long as releasing is performed using a type with
 alignment characteristics similar to what was used at allocation time.

 Olivier

--

Comments part of old patch to is_aligning_offset, explaining what
it was doing:

+   /* The idea is to match a pattern like the one sketched below:
+
+                  |<---------- OFFSET --------->|
+                  +-----------+-----------------+
+                  |           |      .....      |
+                  +-----------+-----------------+
+                  |<- PHASE ->|<---- DELTA ---->|
+                  o                             o
+                  X                        % ALIGN = 0
+      ...
+
+      that is: OFFSET = PHASE + DELTA, with PHASE a constant, ALIGN a power of
+      2 and then (X+OFFSET) % ALIGN == 0, or (X+PHASE+DELTA) % ALIGN == 0.
+
+      We then model DELTA as the "offset from X+PHASE to get to the next
+      address multiple of ALIGN", and expect that value to be expressed as
+      -(X+PHASE) & (ALIGN-1).
+
+      We are then scanning for OFFSETs looking like
+
+        ()
+        PLUS_EXPR
+           ()
+           BIT_AND_EXPR ............o
+              ()                    |
+              NEGATE_EXPR           |
+                 PLUS_EXPR          |  Aligning
+                    ()              |   DELTA
+                    ADDR_EXPR (X)   |
+                    CONST (PHASE)   |
+              ALIGN - 1 ............o
+           CONST (PHASE)
+      ...
+
+      with X either EXP or a placeholder of the same type as EXP's, ALIGN a
+      power of 2, and possible intermediate conversions at the () points.  The
+      conversions might involve integer/size/bitsize types in both directions,
+      hence not preserve modes.
+
+      We also match simplified forms of OFFSET with PHASE = 0, that is:
+
+        ()
+        BIT_AND_EXPR
+           ()
+           NEGATE_EXPR
+              ()
+              ADDR_EXPR (X)
+           ALIGN - 1
+
+       with the same assumptions on X and ALIGN.  */
+