Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
On Mon, Apr 20, 2015 at 9:35 AM, Christian Bruel christian.br...@st.com 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]
On 04/30/2015 09:43 AM, Ramana Radhakrishnan wrote:
On Mon, Apr 20, 2015 at 9:35 AM, Christian Bruel christian.br...@st.com
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]
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]
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 christian.br...@st.com
* 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, bump the number of
Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]
On Mon, Feb 9, 2015 at 12:34 PM, Christian Bruel christian.br...@st.com 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
