On 07/11/2016 05:44 AM, Dominik Vogt wrote:
On Thu, Jul 07, 2016 at 12:57:16PM +0100, Dominik Vogt wrote:
On Wed, Jul 06, 2016 at 02:01:06PM +0200, Bernd Schmidt wrote:
There's one thing I don't quite understand and which seems to have
changed since v1:
On 07/04/2016 02:19 PM, Dominik Vogt wrote:
@@ -1099,8 +1101,10 @@ expand_stack_vars (bool (*pred) (size_t), struct
stack_vars_data *data)
/* If there were any, allocate space. */
if (large_size > 0)
- large_base = allocate_dynamic_stack_space (GEN_INT (large_size), 0,
- large_align, true);
+ {
+ large_allocsize = GEN_INT (large_size);
+ get_dynamic_stack_size (&large_allocsize, 0, large_align, NULL);
+ }
}
for (si = 0; si < n; ++si)
@@ -1186,6 +1190,19 @@ expand_stack_vars (bool (*pred) (size_t), struct
stack_vars_data *data)
/* Large alignment is only processed in the last pass. */
if (pred)
continue;
+
+ if (large_allocsize && ! large_allocation_done)
+ {
+ /* Allocate space the virtual stack vars area in the
+ prologue. */
+ HOST_WIDE_INT loffset;
+
+ loffset = alloc_stack_frame_space
+ (INTVAL (large_allocsize),
+ PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT);
+ large_base = get_dynamic_stack_base (loffset, large_align);
+ large_allocation_done = true;
+ }
gcc_assert (large_base != NULL);
Why is this code split between the two places here?
This is a bugfix from v1 to v2.
I think I had to move this code to the second loop so that the
space for dynamically aligned variables is allocated at the "end"
of the space for stack variables. I cannot remember what the bug
was, but maybe it was that the variables with fixed and static
alignment ended up at the same address.
Anyway, now that the new allocation strategy is used
unconditionally, it should be possible to move the
get_dynamic_stack_size call down to the second loop and simplify
the code somewhat. I'll look into that.
Version 5 with some code moved from the first loop to the second.
-ENOPATCH
jeff
