Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

2015-10-13 Thread Ramana Radhakrishnan
> > yes I see, I was hoping to avoid a new hook, but as you said it seems > mandatory for the mere declaration case. > > Here is one proposal, it defaults to nothing and the ARM implementation does > not need to handle the vptr bit setting. so that simplifies a lot the things. > > The hook

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

2015-10-12 Thread Bernd Schmidt
On 10/12/2015 12:56 PM, Christian Bruel wrote: yes I see, I was hoping to avoid a new hook, but as you said it seems mandatory for the mere declaration case. Here is one proposal, it defaults to nothing and the ARM implementation does not need to handle the vptr bit setting. so that simplifies

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

2015-10-08 Thread Bernd Schmidt
On 10/08/2015 03:14 PM, Christian Bruel wrote: Probably at the time of start_decl, because DECL_ALIGN will have the boundary given by the global target_flags at that time. But this shouldn't be a problem since what matters is the DECL_ALIGN recomputed with the definition when there is something

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

2015-10-08 Thread Bernd Schmidt
On 10/08/2015 03:50 PM, Christian Bruel wrote: Humm, I don't know what kind of alignment optimization for functions we have based on a declaration only. greping DECL_ALIGN on functions there are some bits in the ipa-icf code that seems to merge code using this information, but I think we have a

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

2015-10-08 Thread Bernd Schmidt
On 10/08/2015 04:01 PM, Christian Bruel wrote: OK, Similar pattern occurs at many other places, that changed also in the attached proposal. Not fully tested (in particular the java part) and no ChangeLog. Just to make sure that we agree on the interface first. That looks like a plain diff

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

2015-10-07 Thread Bernd Schmidt
On 10/07/2015 09:04 AM, Christian Bruel wrote: + /* Similarly, relayout function's alignment if not forced. */ + if (!DECL_USER_ALIGN (fndecl) + && (TREE_CODE (fntype) != METHOD_TYPE + || TARGET_PTRMEMFUNC_VBIT_LOCATION != ptrmemfunc_vbit_in_pfn)) +

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

2015-10-07 Thread Bernd Schmidt
On 10/07/2015 12:45 PM, Christian Bruel wrote: On 10/07/2015 12:18 PM, Bernd Schmidt wrote: On 10/07/2015 09:04 AM, Christian Bruel wrote: + /* Similarly, relayout function's alignment if not forced. */ + if (!DECL_USER_ALIGN (fndecl) + && (TREE_CODE (fntype) !=

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

2015-10-07 Thread Jeff Law
On 10/07/2015 01:04 AM, Christian Bruel wrote: The ARM target can switch different alignment requirements between the thumb or arm, thanks to the attribute ((target)). Using FUNCTION_BOUNDARY that now depends on the switchable target_flag. The previous attempt to fix this was to use the

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

2015-10-07 Thread Bernd Schmidt
On 10/07/2015 07:37 PM, Bernd Schmidt wrote: On 10/07/2015 12:45 PM, Christian Bruel wrote: On 10/07/2015 12:18 PM, Bernd Schmidt wrote: On 10/07/2015 09:04 AM, Christian Bruel wrote: + /* Similarly, relayout function's alignment if not forced. */ + if (!DECL_USER_ALIGN (fndecl)

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

2015-09-30 Thread Jeff Law
On 09/29/2015 07:24 AM, Christian Bruel wrote: This patch uses FUNCTION_BOUNDARY instead of DECL_ALIGN to check the max align when optimizing for size in assemble_start_function. This is necessary for ARM that can switch the max code alignment directives between modes. No regressions for ARM