[PATCH, ARM] attribute target (thumb,arm) [0/6] respin (4th)
> A general note, please reply to each of the patches with a rebased > patch as a separate email. Further more all your patches appear to > have dos line endings so they don't seem to apply cleanly. Please > don't have spurious headers in your patch submission - it then makes > it hard to , please create it in a way that it is easily applied by > someone trying it out. It looks like p4 needs a respin as I got a > reject trying to apply the documentation patch to my tree while trying > to apply it. > lets go... rebased (4th time since 2014 !), no conflicts. so here is the attribute revisited / rebased , so - thumb1 is now supported - -mflip-thump option added for testing. - inlining is allowed between modes. This set of patches was tested on arm-none-eabi as: no regressions with: arm-sim/ arm-sim/-march=armv7-a arm-sim/-mthumb arm-sim/-mthumb/-march=armv7-a a few artifacts, all of them analyzed, with arm-sim/-mflip-thumb/ arm-sim/-mflip-thumb//-march=armv7-a arm-sim/-mflip-thumb//-mthumb arm-sim/-mflip-thumb//-mthumb/-march=armv7-a Artifacts are analyzed, they are mostly the fault of the testsuite being unable to mix modes in the expected results (e.g thumb[1,2] or arm tests predicates, mix setjmp/longjump between modes...) The support is split as followed: [1/6] Reorganized arm_option_override to dynamically redefine the flags depending on the attribute mode. [2/6] Reorganized macro settings to be set/unset for each #pragma targets [3/6] Change ARM_DECLARE_FUNCTION_NAME into a function [4/6] Implement hooks to support attribute target [5/6] Implement #pragma target [6/6] Add -mflip-thumb option for testing thanks Christian
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
Christian A general note, please reply to each of the patches with a rebased patch as a separate email. Further more all your patches appear to have dos line endings so they don't seem to apply cleanly. Please don't have spurious headers in your patch submission - it then makes it hard to , please create it in a way that it is easily applied by someone trying it out. It looks like p4 needs a respin as I got a reject trying to apply the documentation patch to my tree while trying to apply it. OK, thanks for the suggestions and sorry for the p4 reject. The sources are moving fast and I have hard times catching up with re-bases. I understand. I tried the following decoration on foo in gcc.target/arm/attr_arm.c int __attribute__((target("arm, fpu=vfpv4"))) foo(int a) { return a ? 1 : 5; } And the compiler accepts it just fine. Indeed, it's a mistake for now. attributes other the arm/thumb ones shall be rejected (eventually with a "not yet implemented" warning for the fpu, error for the others.) until we extend it. Yep - funnily enough if you remove "arm" and just use "fpu=vfpv4", I think you get an error. Given that with LTO we are now using target attributes to decide inlining - I'm not convinced that the inline asm case goes away. In fact it only makes things worse so I'm almost convinced to forbid inlining from "arm" to "thumb" or vice-versa, which is a reversal of my earlier position. I hadn't twigged that LTO would reuse this infrastructure and it's probably simpler to prevent inlining in those cases. I can resurrect the inline check chunk. FYI, with a few small examples arm/thumb attribute is correctly handled by LTO Yes it would work with normal C code as it does normally - I'm worried about functions with inline asm. We've just increased the inlining scope with lto and that would mean things are a bit more painful ? Thoughts ? So in essence I'm still playing with this and would like to iterate towards a quick solution. thanks, that would be good if we could land the arm/thumb attribute and start the fpu extensions separately. (I'm currently playing with fpu=neon but it will take time to have something solid). Absolutely - I'd rather spend the time first in polishing this up. Extending it for other options can be something you look at separately. BTW I was pointed at a PR for this yesterday by a colleague - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884 So, lets use that as the PR for this work. regards Ramana Christian Ramana
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
On 04/30/2015 09:43 AM, Ramana Radhakrishnan wrote: > On Mon, Apr 20, 2015 at 9:35 AM, Christian Bruel > wrote: >> Hello Ramana >> >>> >>> Can you respin this now that we are in stage1 again ? >>> >>> Ramana >>> >> >> Attached the rebased, rechecked set of patches. Original with comments >> posted in >> >> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.html >> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02458.html >> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02460.html >> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02461.html >> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02463.html >> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02467.html >> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02468.html >> >> many thanks, >> >> Christian > > > A general note, please reply to each of the patches with a rebased > patch as a separate email. Further more all your patches appear to > have dos line endings so they don't seem to apply cleanly. Please > don't have spurious headers in your patch submission - it then makes > it hard to , please create it in a way that it is easily applied by > someone trying it out. It looks like p4 needs a respin as I got a > reject trying to apply the documentation patch to my tree while trying > to apply it. > OK, thanks for the suggestions and sorry for the p4 reject. The sources are moving fast and I have hard times catching up with re-bases. > I tried the following decoration on foo in gcc.target/arm/attr_arm.c > > > int __attribute__((target("arm, fpu=vfpv4"))) > foo(int a) > { > return a ? 1 : 5; > } > > > And the compiler accepts it just fine. Indeed, it's a mistake for now. attributes other the arm/thumb ones shall be rejected (eventually with a "not yet implemented" warning for the fpu, error for the others.) until we extend it. > > Given that with LTO we are now using target attributes to decide > inlining - I'm not convinced that the inline asm case goes away. In > fact it only makes things worse so I'm almost convinced to forbid > inlining from "arm" to "thumb" or vice-versa, which is a reversal of > my earlier position. I hadn't twigged that LTO would reuse this > infrastructure and it's probably simpler to prevent inlining in those > cases. I can resurrect the inline check chunk. FYI, with a few small examples arm/thumb attribute is correctly handled by LTO > > Thoughts ? > > So in essence I'm still playing with this and would like to iterate > towards a quick solution. > thanks, that would be good if we could land the arm/thumb attribute and start the fpu extensions separately. (I'm currently playing with fpu=neon but it will take time to have something solid). Christian > Ramana >
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
On Mon, Apr 20, 2015 at 9:35 AM, Christian Bruel wrote: > Hello Ramana > >>> >> >> Can you respin this now that we are in stage1 again ? >> >> Ramana >> > > Attached the rebased, rechecked set of patches. Original with comments > posted in > > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02458.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02460.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02461.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02463.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02467.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02468.html > > many thanks, > > Christian A general note, please reply to each of the patches with a rebased patch as a separate email. Further more all your patches appear to have dos line endings so they don't seem to apply cleanly. Please don't have spurious headers in your patch submission - it then makes it hard to , please create it in a way that it is easily applied by someone trying it out. It looks like p4 needs a respin as I got a reject trying to apply the documentation patch to my tree while trying to apply it. I tried the following decoration on foo in gcc.target/arm/attr_arm.c int __attribute__((target("arm, fpu=vfpv4"))) foo(int a) { return a ? 1 : 5; } And the compiler accepts it just fine. Given that with LTO we are now using target attributes to decide inlining - I'm not convinced that the inline asm case goes away. In fact it only makes things worse so I'm almost convinced to forbid inlining from "arm" to "thumb" or vice-versa, which is a reversal of my earlier position. I hadn't twigged that LTO would reuse this infrastructure and it's probably simpler to prevent inlining in those cases. Thoughts ? So in essence I'm still playing with this and would like to iterate towards a quick solution. Ramana
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
Hello Ramana >> > > Can you respin this now that we are in stage1 again ? > > Ramana > Attached the rebased, rechecked set of patches. Original with comments posted in https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02458.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02460.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02461.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02463.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02467.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02468.html many thanks, Christian 2014-09-23 Christian Bruel * config/arm/arm.h (arm_option_override): Reoganized and split. (arm_option_params_internal); New function. (arm_option_check_internal): New function. (arm_option_override_internal): New function. (restrict_default): New boolean. (thumb_code, thumb1_code): Remove. * config/arm/arm.h (TREE_TARGET_THUMB, TREE_TARGET_THUMB1): New macros. (TREE_TARGET_THUM2, TREE_TARGET_ARM): Likewise. (thumb_code, thumb1_code): Remove. * config/arm/arm.md (is_thumb, is_thumb1): Check TARGET flag. diff -ruN '--exclude=.svn' a/gcc/gcc/config/arm/arm.c a1/gcc/gcc/config/arm/arm.c --- a/gcc/gcc/config/arm/arm.c 2015-02-04 09:14:26.120602737 +0100 +++ a1/gcc/gcc/config/arm/arm.c 2015-02-05 09:19:32.853338616 +0100 @@ -846,12 +846,6 @@ /* Nonzero if tuning for Cortex-A9. */ int arm_tune_cortex_a9 = 0; -/* Nonzero if generating Thumb instructions. */ -int thumb_code = 0; - -/* Nonzero if generating Thumb-1 instructions. */ -int thumb1_code = 0; - /* Nonzero if we should define __THUMB_INTERWORK__ in the preprocessor. XXX This is a bit of a hack, it's intended to help work around @@ -2623,6 +2617,148 @@ return std_gimplify_va_arg_expr (valist, type, pre_p, post_p); } +/* Check any incompatible options that the user has specified. */ +static void +arm_option_check_internal (struct gcc_options *opts) +{ + /* Make sure that the processor choice does not conflict with any of the + other command line choices. */ + if (TREE_TARGET_ARM (opts) && !(insn_flags & FL_NOTM)) +error ("target CPU does not support ARM mode"); + + /* TARGET_BACKTRACE calls leaf_function_p, which causes a crash if done + from here where no function is being compiled currently. */ + if ((TARGET_TPCS_FRAME || TARGET_TPCS_LEAF_FRAME) && TREE_TARGET_ARM (opts)) +warning (0, "enabling backtrace support is only meaningful when compiling for the Thumb"); + + if (TREE_TARGET_ARM (opts) && TARGET_CALLEE_INTERWORKING) +warning (0, "enabling callee interworking support is only meaningful when compiling for the Thumb"); + + /* If this target is normally configured to use APCS frames, warn if they + are turned off and debugging is turned on. */ + if (TREE_TARGET_ARM (opts) + && write_symbols != NO_DEBUG + && !TARGET_APCS_FRAME + && (TARGET_DEFAULT & MASK_APCS_FRAME)) +warning (0, "-g with -mno-apcs-frame may not give sensible debugging"); + + /* iWMMXt unsupported under Thumb mode. */ + if (TREE_TARGET_THUMB (opts) && TARGET_IWMMXT) +error ("iWMMXt unsupported under Thumb mode"); + + if (TARGET_HARD_TP && TREE_TARGET_THUMB1 (opts)) +error ("can not use -mtp=cp15 with 16-bit Thumb"); + + if (TREE_TARGET_THUMB (opts) && TARGET_VXWORKS_RTP && flag_pic) +{ + error ("RTP PIC is incompatible with Thumb"); + flag_pic = 0; +} + + /* We only support -mslow-flash-data on armv7-m targets. */ + if (target_slow_flash_data + && ((!(arm_arch7 && !arm_arch_notm) && !arm_arch7em) + || (TREE_TARGET_THUMB1 (opts) || flag_pic || TARGET_NEON))) +error ("-mslow-flash-data only supports non-pic code on armv7-m targets"); +} + +/* Check any params depending on attributes that the user has specified. */ +static void +arm_option_params_internal (struct gcc_options *opts) +{ + /* If we are not using the default (ARM mode) section anchor offset + ranges, then set the correct ranges now. */ + if (TREE_TARGET_THUMB1 (opts)) +{ + /* Thumb-1 LDR instructions cannot have negative offsets. + Permissible positive offset ranges are 5-bit (for byte loads), + 6-bit (for halfword loads), or 7-bit (for word loads). + Empirical results suggest a 7-bit anchor range gives the best + overall code size. */ + targetm.min_anchor_offset = 0; + targetm.max_anchor_offset = 127; +} + else if (TREE_TARGET_THUMB2 (opts)) +{ + /* The minimum is set such that the total size of the block + for a particular anchor is 248 + 1 + 4095 bytes, which is + divisible by eight, ensuring natural spacing of anchors. */ + targetm.min_anchor_offset = -248; + targetm.max_anchor_offset = 4095; +} + else +{ + targetm.min_anchor_offset = TARGET_MIN_ANCHOR_OFFSET; + targetm.max_anchor_offset = TARGET_MAX_ANCHOR_OFFSET; +} + + if (optimize_size) +{ + /* If optimizing for size,
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
On Mon, Feb 9, 2015 at 12:34 PM, Christian Bruel wrote: > Hello, > > I'd like to ping with a respin of the 7 patches for > the attribute target (thumb,arm) [0-6] : > > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02458.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02460.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02461.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02463.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02467.html > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02468.html > > In order to fix the various conflicts that have happened since, please find > attached the re-based patches to trunk rev #220529 (respectively from above > p0.patch, p1.patch, p2,patch, p3.patch, p4,patch, p5,patch, p6,patch). > > I understand the difficulty of reviewing those due to the code > reorganization, but maintaining them are really a pain since a conflict > happens at almost every update in the ARM back-end :-( > > Comments, questions are welcome, > > Many thanks > > Christian > > > > Can you respin this now that we are in stage1 again ? Ramana
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
In order to fix the various conflicts that have happened since, please find attached the re-based patches to trunk rev #220529 (respectively from above p0.patch, p1.patch, p2,patch, p3.patch, p4,patch, p5,patch, p6,patch). oops, please don't review p0.patch here. This last one will be reviewed separately by the i386 and middle-end maintainers. It was posted now accidentally and is useful only for testing. Thanks Christian
ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
Hello, I'd like to ping with a respin of the 7 patches for the attribute target (thumb,arm) [0-6] : https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02458.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02460.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02461.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02463.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02467.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02468.html In order to fix the various conflicts that have happened since, please find attached the re-based patches to trunk rev #220529 (respectively from above p0.patch, p1.patch, p2,patch, p3.patch, p4,patch, p5,patch, p6,patch). I understand the difficulty of reviewing those due to the code reorganization, but maintaining them are really a pain since a conflict happens at almost every update in the ARM back-end :-( Comments, questions are welcome, Many thanks Christian Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 220436) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,11 @@ +2015-02-06 Christian Bruel + + PR target/64835 + * config/i386/i386.c (ix86_default_align): New function. + (ix86_override_options_after_change): Call ix86_default_align. + (TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): New hook. + (ix86_override_options_after_change): New function. + 2015-02-04 Jan Hubicka Trevor Saunders Index: gcc/config/i386/i386.c === --- gcc/config/i386/i386.c (revision 220436) +++ gcc/config/i386/i386.c (working copy) @@ -3105,6 +3105,35 @@ } +/* Default align_* from the processor table. */ + +static void +ix86_default_align (struct gcc_options *opts) +{ + if (opts->x_align_loops == 0) +{ + opts->x_align_loops = processor_target_table[ix86_tune].align_loop; + align_loops_max_skip = processor_target_table[ix86_tune].align_loop_max_skip; +} + if (opts->x_align_jumps == 0) +{ + opts->x_align_jumps = processor_target_table[ix86_tune].align_jump; + align_jumps_max_skip = processor_target_table[ix86_tune].align_jump_max_skip; +} + if (opts->x_align_functions == 0) +{ + opts->x_align_functions = processor_target_table[ix86_tune].align_func; +} +} + +/* Implement TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE hook. */ + +static void +ix86_override_options_after_change (void) +{ + ix86_default_align (&global_options); +} + /* Override various settings based on options. If MAIN_ARGS_P, the options are from the command line, otherwise they are from attributes. */ @@ -3902,20 +3931,7 @@ opts->x_ix86_regparm = REGPARM_MAX; /* Default align_* from the processor table. */ - if (opts->x_align_loops == 0) -{ - opts->x_align_loops = processor_target_table[ix86_tune].align_loop; - align_loops_max_skip = processor_target_table[ix86_tune].align_loop_max_skip; -} - if (opts->x_align_jumps == 0) -{ - opts->x_align_jumps = processor_target_table[ix86_tune].align_jump; - align_jumps_max_skip = processor_target_table[ix86_tune].align_jump_max_skip; -} - if (opts->x_align_functions == 0) -{ - opts->x_align_functions = processor_target_table[ix86_tune].align_func; -} + ix86_default_align (opts); /* Provide default for -mbranch-cost= value. */ if (!opts_set->x_ix86_branch_cost) @@ -51928,6 +51944,9 @@ #undef TARGET_PROMOTE_FUNCTION_MODE #define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode +#undef TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE +#define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE ix86_override_options_after_change + #undef TARGET_MEMBER_TYPE_FORCES_BLK #define TARGET_MEMBER_TYPE_FORCES_BLK ix86_member_type_forces_blk Index: gcc/dwarf2cfi.c === --- gcc/dwarf2cfi.c (revision 220436) +++ gcc/dwarf2cfi.c (working copy) @@ -2941,7 +2941,6 @@ dw_trace_info cie_trace; dw_stack_pointer_regnum = DWARF_FRAME_REGNUM (STACK_POINTER_REGNUM); - dw_frame_pointer_regnum = DWARF_FRAME_REGNUM (HARD_FRAME_POINTER_REGNUM); memset (&cie_trace, 0, sizeof (cie_trace)); cur_trace = &cie_trace; @@ -2994,6 +2993,9 @@ static unsigned int execute_dwarf2_frame (void) { + /* Different HARD_FRAME_POINTER_REGNUM might coexist in the same file. */ + dw_frame_pointer_regnum = DWARF_FRAME_REGNUM (HARD_FRAME_POINTER_REGNUM); + /* The first time we're called, compute the incoming frame state. */ if (cie_cfi_vec == NULL) create_cie_data (); Index: gcc/ipa-inline.c === --- gcc/ipa-inline.c (revision 220436) +++ gcc/ipa-inline.c (working copy) @@ -489,7 +489,7 @@ else if (opt_for_fn (callee->decl, optimize_size) < opt_for_fn (caller->decl, optimize_size) || (opt_for_fn (callee->decl, optimize) - >= op
Re: [PATCH, ARM] attribute target (thumb,arm) [0/6]
Hi Ramana, On 11/27/2014 11:36 AM, Ramana Radhakrishnan wrote: On Wed, Nov 19, 2014 at 2:54 PM, Christian Bruel wrote: On 11/19/2014 03:18 PM, Ramana Radhakrishnan wrote: On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel wrote: I think I missed the stage3, Anyway would it be OK for stage1 when it reopens ? Since you submitted this well during stage1 and given that these patches address comments from earlier in the review process we should aim to get these in for 5.0. If at some point during the review process it looks risky and there needs to be significant rework we can always stop. It's on the list of patches to be reviewed and I will find some dedicated time later this week to set down and review / play with the patches in an attempt to move this forward as it is a reasonably large chunk of work. Thanks, also I forgot to mention that you need https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01231.html to play with the attribute. Will be part of the same shot. Isn't that Ok'd for committing ? Why then isn't it applied ? yes it was, it is in my single changeset with the attribute target since itÅ› the only way to trigger the issue. Cheers Christian Ramana Christian Thanks for continuing to work on these patches and addressing the earlier review comments. regards Ramana Christian
Re: [PATCH, ARM] attribute target (thumb,arm) [0/6]
On Wed, Nov 19, 2014 at 2:54 PM, Christian Bruel wrote: > > > On 11/19/2014 03:18 PM, Ramana Radhakrishnan wrote: >> >> On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel >> wrote: >> >>> I think I missed the stage3, Anyway would it be OK for stage1 when it >>> reopens ? >> >> >> Since you submitted this well during stage1 and given that these >> patches address comments from earlier in the review process we should >> aim to get these in for 5.0. If at some point during the review >> process it looks risky and there needs to be significant rework we can >> always stop. It's on the list of patches to be reviewed and I will >> find some dedicated time later this week to set down and review / play >> with the patches in an attempt to move this forward as it is a >> reasonably large chunk of work. > > > Thanks, also I forgot to mention that you need > https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01231.html > to play with the attribute. Will be part of the same shot. Isn't that Ok'd for committing ? Why then isn't it applied ? Ramana > > Christian > > >> >> Thanks for continuing to work on these patches and addressing the >> earlier review comments. >> >> regards >> Ramana >> >>> >>> Christian >>> >
Re: [PATCH, ARM] attribute target (thumb,arm) [0/6]
On 11/19/2014 03:18 PM, Ramana Radhakrishnan wrote: On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel wrote: I think I missed the stage3, Anyway would it be OK for stage1 when it reopens ? Since you submitted this well during stage1 and given that these patches address comments from earlier in the review process we should aim to get these in for 5.0. If at some point during the review process it looks risky and there needs to be significant rework we can always stop. It's on the list of patches to be reviewed and I will find some dedicated time later this week to set down and review / play with the patches in an attempt to move this forward as it is a reasonably large chunk of work. Thanks, also I forgot to mention that you need https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01231.html to play with the attribute. Will be part of the same shot. Christian Thanks for continuing to work on these patches and addressing the earlier review comments. regards Ramana Christian
Re: [PATCH, ARM] attribute target (thumb,arm) [0/6]
On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel wrote: > I think I missed the stage3, Anyway would it be OK for stage1 when it > reopens ? Since you submitted this well during stage1 and given that these patches address comments from earlier in the review process we should aim to get these in for 5.0. If at some point during the review process it looks risky and there needs to be significant rework we can always stop. It's on the list of patches to be reviewed and I will find some dedicated time later this week to set down and review / play with the patches in an attempt to move this forward as it is a reasonably large chunk of work. Thanks for continuing to work on these patches and addressing the earlier review comments. regards Ramana > > Christian >
[PATCH, ARM] attribute target (thumb,arm) [0/6]
Hello Ramana, Here is the attribute revisited after your comments, so - thumb1 is now supported - -mflip-thump option added for testing. - inlining is allowed between modes. This set of patches was tested on rev#217709 as: no regressions with: arm-sim/ arm-sim/-march=armv7-a arm-sim/-mthumb arm-sim/-mthumb/-march=armv7-a a few artifacts, all of them analyzed, with arm-sim/-mflip-thumb/ arm-sim/-mflip-thumb//-march=armv7-a arm-sim/-mflip-thumb//-mthumb arm-sim/-mflip-thumb//-mthumb/-march=armv7-a Artifacts are analyzed, they are mostly the fault of the testsuite being unable to mix modes in the expected results (e.g thumb[1,2] or arm tests predicates, mix setjmp/longjump between modes...) The support is split as followed: [1/6] Reorganized arm_option_override to dynamically redefine the flags depending on the attribute mode. [2/6] Reorganized macro settings to be set/unset for each #pragma targets [3/6] Change ARM_DECLARE_FUNCTION_NAME into a function [4/6] Implement hooks to support attribute target [5/6] Implement #pragma target [6/6] Add -mflip-thumb option for testing I think I missed the stage3, Anyway would it be OK for stage1 when it reopens ? Christian