On Tue, Aug 4, 2015 at 11:50 AM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Tue, Aug 4, 2015 at 10:43 AM, Segher Boessenkool > <seg...@kernel.crashing.org> wrote: >> On Tue, Aug 04, 2015 at 10:28:00AM -0700, H.J. Lu wrote: >>> >> Any comments on my middle-end patch? >>> > >>> > So, if the answer is the same as frame_address (0), why not have the >>> > fallback just expand to that? Then, one can use this builtin everywhere >>> > that frame address is used today. People that want a faster, tighter >>> > port can then implement the hook and achieve higher performance. >>> >>> The motivation of __builtin_stack_top is that frame_address requires a >>> frame pointer register, which isn't desirable for x86. __builtin_stack_top >>> doesn't require a frame pointer register. >> >> If the target just returns frame_pointer_rtx from INITIAL_FRAME_ADDRESS_RTX, >> you don't get crtl->accesses_prior_frames set either, and as far as I can >> see everything works fine? For __builtin_frame_address(0). >> >> You might have a reason why you want the entry stack address instead of the >> frame address, but you didn't really explain I think? Or I missed it. >> > > expand_builtin_return_addr sets > > crtl->accesses_prior_frames = 1; > > for __builtin_frame_address, which requires a frame pointer register. > __builtin_stack_top doesn't set crtl->accesses_prior_frames and frame > pointer register isn't required. >
BTW, x86 doesn't define INITIAL_FRAME_ADDRESS_RTX. -- H.J.
