kward workarounds.
diff --git a/gcc/combine.c b/gcc/combine.c
index 93bd3da26d7..fdc79ab7d3e 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -,17 +,7 @@ make_extraction (machine_mode mode, rtx inner,
HOST_WIDE_INT pos,
This patch is against some older version of combine.c? The line numb
, then your machine description has
to recognise X (perhaps in addition to other ways it can be written), or
you will not get as much optimisation as you might like: some combine
attempts will fail.
> combine should adapt to the target.
How?
> diff --git a/gcc/combine.c b/gcc/combine.c
&g
at a read outside of the original
object bounds is if the size is expanded. There's code in combine.c to
insure that does not happen. I guess that an extv could be generated
with incorrect operands which would be outside the object bounds, but
that would be a bug.
I don't doubt th
On 11/21/18 9:33 AM, Segher Boessenkool wrote:
> On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:
>> The internal RTL should not be dictating what the target arch can or
>> cannot implement. Reload should insert any needed conversions,
>> especially ones which narrow the size.
>
>
On 11/21/18 11:47, Segher Boessenkool wrote:
On Wed, Nov 21, 2018 at 08:52:21AM -0800, Michael Eager wrote:
On 11/21/2018 08:33 AM, Segher Boessenkool wrote:
On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:
The internal RTL should not be dictating what the target arch can or
cann
On Wed, Nov 21, 2018 at 08:52:21AM -0800, Michael Eager wrote:
> On 11/21/2018 08:33 AM, Segher Boessenkool wrote:
> >On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:
> >>The internal RTL should not be dictating what the target arch can or
> >>cannot implement. Reload should insert a
On 11/21/2018 08:33 AM, Segher Boessenkool wrote:
On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:
The internal RTL should not be dictating what the target arch can or
cannot implement. Reload should insert any needed conversions,
especially ones which narrow the size.
Well, tha
On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:
> The internal RTL should not be dictating what the target arch can or
> cannot implement. Reload should insert any needed conversions,
> especially ones which narrow the size.
Well, that depends. A zero_extract of mem is only defi
On 11/20/18 11:07 AM, Michael Eager wrote:
> On 11/18/2018 08:14 AM, Jeff Law wrote:
>> On 11/18/18 8:44 AM, Michael Eager wrote:
>>> On 11/16/18 14:50, Segher Boessenkool wrote:
Hi!
On Wed, Nov 14, 2018 at 11:22:58AM -0800, Michael Eager wrote:
> The (mem:SI) is converted to (me
On 11/18/2018 08:14 AM, Jeff Law wrote:
On 11/18/18 8:44 AM, Michael Eager wrote:
On 11/16/18 14:50, Segher Boessenkool wrote:
Hi!
On Wed, Nov 14, 2018 at 11:22:58AM -0800, Michael Eager wrote:
The (mem:SI) is converted to (mem:QI).
The return from make_extract() is
(zero_extract:SI (me
to make_extraction().
Eventually (combine.c:7753), make_extract() decides that the best
pattern is EP_epextzv. No instruction patterns are provided for
"extz*"; get_best_reg_extraction_insn() returns false, and
make_extraction falls through to this code [indenting modified for
email].
On Fri, Jul 29, 2016 at 11:05:13AM +0200, Georg-Johann Lay wrote:
> There might still problems linger around if hard-regs are used:
>
> Suppose we set the reg in DImode and then get_last_value is called for the
> same reg in SImode. Using the DI value might be wrong, e.g. if it is used
> to com
value might be wrong, e.g. if it is used to
compute the sign (on little endian) or the number of sign bit copies.
Anyway, for now I am happy with the current solution. Many thanks for your
patient help.
Johann
Segher
diff --git a/gcc/combine.c b/gcc/combine.c
index 77e0d2b..750bf83 1
Hi Johann,
I tested a variant of your patch, building Linux for 32 different
(sub-)architectures; surprisingly (to me) there are no regressions
at all.
Do you want to send it to gcc-patches?
Segher
diff --git a/gcc/combine.c b/gcc/combine.c
index 77e0d2b..750bf83 100644
--- a/gcc/combine.c
On Wed, Jul 27, 2016 at 09:14:27PM +0200, Georg-Johann Lay wrote:
> >diff --git a/gcc/combine.c b/gcc/combine.c
> >index 77e0d2b..dec6226 100644
> >--- a/gcc/combine.c
> >+++ b/gcc/combine.c
> >@@ -9977,6 +9977,9 @@ reg_num_sign_bit_copies_for_combine (cons
parts and then put them together...
Yes, and the rsp stuff does not do that.
I am testing the following patch. Thanks,
Segher
diff --git a/gcc/combine.c b/gcc/combine.c
index 77e0d2b..dec6226 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -9977,6 +9977,9 @@ reg_num_sign_bit_copies_for
ormation. From a set of 8 bits you cannot draw conclusion about all 64
> bits; this should be obvious enough :-)
:-)
> In the above case rsp[regno] holds only information for 1 sub-byte. In
> order to get the complete DImode story we would have to get the info for
> all sub-parts a
of the hard register bits are set to unspecified values.
No, insns 44...50 set the rest of reg:DI 18 to specified values. This is what
expand does as is lowers DImode to word_mode (QImode for avr).
FYI, FIRST_PSEUDO_REGISTER is 34.
thus the code should never reach this point in the
first pl
to unspecified values.
> thus the code should never reach this point in the
> first place and return earlier. For example:
>
> Index: combine.c
> ===
> --- combine.c (revision 238701)
> +++ combine.c (
to be -1 or 0
is a no-op. */
if (code == ASHIFTRT
&& (num_sign_bit_copies (varop, shift_mode)
== GET_MODE_PRECISION (shift_mode)))
{
count = 0;
break;
}
num_sign_bit_copies() eventually calls
c
known to be -1 or 0
>is a no-op. */
> if (code == ASHIFTRT
> && (num_sign_bit_copies (varop, shift_mode)
> == GET_MODE_PRECISION (shift_mode)))
> {
> count = 0;
> break;
> }
>
> num_sign_bit_c
Tracking this wrong-code bug, I ended up in combine.c::get_last_value() which
returns a wrong result. gcc generates wrong code at least with: 4.9 head, 5.2,
6.1 and trunk from today.
Before combine we have:
(insn 43 31 44 2 (set (reg:QI 18 r18)
(const_int 0 [0])) bug-combin.c:29 56
I'm pleased to announce that Segher Boessenkool has been appointed as
maintainer for instruction combiner (combine.c).
Segher, can you please add yourself to the MAINTAINERS file for the
additional role.
Thanks,
jeff
This is a tentative patch to fix combine.c so that it no more reorders volatile
memory accesses.
Even reading volatile memory can change other (volatile) memory as explained
in the patch. This also applies to volatile memory that is not wired to
hardware that changes by magic when reading: An
On 01/05/2010 07:12 AM, Matt wrote:
Hi,
I'm fixing some compiler errors when configuring with
--enable-build-with-cxx, and ran into a curious line of code that may
indicate a bug:
static unsigned int
rest_of_handle_combine (void)
{
int rebuild_jump_labels_after_combine;
df_set_flags (DF_LR_RUN
Hi,
I'm fixing some compiler errors when configuring with
--enable-build-with-cxx, and ran into a curious line of code that may
indicate a bug:
static unsigned int
rest_of_handle_combine (void)
{
int rebuild_jump_labels_after_combine;
df_set_flags (DF_LR_RUN_DCE + DF_DEFER_INSN_RESCAN);
Rajkishore Barik <[EMAIL PROTECTED]> writes:
> Can someone tell me why are the "REG_VALUE_PROFILE" notes
> dropped in "combine.c"? I am using these notes to carry some values to
> back-end (reg-alloc)
> and it seems to get lost somewhere. "combine.c&quo
Can someone tell me why are the "REG_VALUE_PROFILE" notes
dropped in "combine.c"? I am using these notes to carry some values to
back-end (reg-alloc)
and it seems to get lost somewhere. "combine.c" looked to me as the
potential place.
--Raj
28 matches
Mail list logo
