p is because both the high and
> overflow handling expects the high half to start at a limb boundary
> the bits of the result starting with bit 65 are shifted up by 63 such
> that the bits relevant for high/need_overflow start at the half of the
> 4th half wide int limb.
> Becau
ply these. Next step is because both the high and
> overflow handling expects the high half to start at a limb boundary
> the bits of the result starting with bit 65 are shifted up by 63 such
> that the bits relevant for high/need_overflow start at the half of the
> 4th half wide int li
limb boundary
the bits of the result starting with bit 65 are shifted up by 63 such
that the bits relevant for high/need_overflow start at the half of the
4th half wide int limb.
Because both operands are negative that part is then adjusted.
The reason mul_internal says there is overflow is becau
On Tue, 6 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> As the following testcases show, the overflow (needs_overflow) and high
> handling in wi::mul_internal seem to only work correctly for either
> small precisions (less than or equal to 32, that is handled by earlier
> simpler code, not the full Kn
Hi!
As the following testcases show, the overflow (needs_overflow) and high
handling in wi::mul_internal seem to only work correctly for either
small precisions (less than or equal to 32, that is handled by earlier
simpler code, not the full Knuth's multiplication algorithm) or for
precisions whic
> Am 03.02.2024 um 09:46 schrieb Jakub Jelinek :
>
> Hi!
>
> Since bswap has been converted from a method to a function we miscompile
> the following testcase. The problem is the assumption that the passed in
> len argument (number of limbs in the xval array) is the upper bound for the
> bsw
Hi!
Since bswap has been converted from a method to a function we miscompile
the following testcase. The problem is the assumption that the passed in
len argument (number of limbs in the xval array) is the upper bound for the
bswap result, which is true only if precision is <= 64. If precision i
On Wed, 29 Nov 2023, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes the other half of the PR, where we were crashing on the
> UNSIGNED widest_int modulo of 1 % -128 (where the -128 in UNSIGNED is
> 131072 bit 0xf...f80).
> The patch actually has 2 independent parts, if you want, they cou
Hi!
This patch fixes the other half of the PR, where we were crashing on the
UNSIGNED widest_int modulo of 1 % -128 (where the -128 in UNSIGNED is
131072 bit 0xf...f80).
The patch actually has 2 independent parts, if you want, they could be
split out.
The fix for the divmod buffer overflow
th one come
> from? Of course all of these assuming HOST_BITS_PER_WIDE_INT is a multiple
> of 64...
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Thanks,
Richard.
> 2023-10-17 Jakub Jelinek
>
> * wide-int-print.h (print_dec_buf_size):
r trunk?
2023-10-17 Jakub Jelinek
* wide-int-print.h (print_dec_buf_size): For length, divide number
of bits by 3 and add 3 instead of division by 4 and adding 4.
* wide-int-print.cc (print_decs): Remove superfluous ()s. Don't call
print_hex, instead call pri
stead of hex numbers by print_dec*, where we'd only need to adjust
> the inlines. The XALLOCAVEC call is left for the callers, those would
> make the inlines uninlinable and not doing what they should.
LGTM.
Richard
> 2023-10-14 Jakub Jelinek
>
> PR tree-optimization/1118
is left for the callers, those would
make the inlines uninlinable and not doing what they should.
2023-10-14 Jakub Jelinek
PR tree-optimization/111800
gcc/
* wide-int-print.h (print_dec_buf_size, print_decs_buf_size,
print_decu_buf_size, print_hex_buf_size): New inline f
widest_int).
>
> 2023-10-14 Jakub Jelinek
>
>PR tree-optimization/111800
> gcc/
>* wide-int.cc (assert_deceq): Use wi.get_len () for buffer size
>estimation only if !wi::neg_p (wi) or if len is 1 and sgn is SIGNED,
> otherwise use WIDE_INT_MAX_HWIS
get_len () for buffer size estimation only
if !wi::neg_p (wi), otherwise use WIDE_INT_MAX_HWIS for
wi.get_precision ().
* wide-int-print.cc (print_decs): Use wi.get_len () for buffer size
estimation only if !wi::neg_p (wi) or if len is 1, otherwise use
WIDE_INT_MA
Hi!
While my wide_int patch bootstrapped/regtested fine when I used GCC 12
as system gcc, apparently it doesn't with GCC 11 and older or clang++.
For GCC before PR96555 C++ DR1315 implementation the compiler complains
about template argument involving template parameters, for clang++ the
same + co
ns). */
>unsigned int blocks_needed = BLOCKS_NEEDED (xprecision - shift);
> - unsigned int len = blocks_needed;
> - if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS) && len > xlen)
> -len = xlen;
> + unsigned int len = MIN (xlen, blocks_needed);
>
>rsh
nt bits
(excluding the upper zeros or signs). */
unsigned int blocks_needed = BLOCKS_NEEDED (xprecision - shift);
- unsigned int len = blocks_needed;
- if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS) && len > xlen)
-len = xlen;
+ unsigned int len = MIN (xlen, blocks_nee
gns). */
> + unsigned int blocks_needed = BLOCKS_NEEDED (xprecision - shift);
> + unsigned int len = blocks_needed;
> + if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS) && len > xlen)
> +len = xlen;
> +
Same here.
OK for thw wide-int parts with those changes.
Thanks,
Richard
On Tue, Oct 10, 2023 at 06:41:50PM +0100, Richard Sandiford wrote:
> > On the wide_int side, I see
> > 155291 576
> > (supposedly because of bound_wide_int, where we create wide_int_ref from
> > the 576-bit precision bound_wide_int and then create 576-bit wide_int when
> > using unary or binary op
Jakub Jelinek writes:
> On Mon, Oct 09, 2023 at 03:44:10PM +0200, Jakub Jelinek wrote:
>> Thanks, just quick answers, will work on patch adjustments after trying to
>> get rid of rwide_int (seems dwarf2out has very limited needs from it, just
>> some routine to construct it in GCed memory (and nev
On Tue, Oct 10, 2023 at 09:30:31AM +, Richard Biener wrote:
> On Mon, 9 Oct 2023, Jakub Jelinek wrote:
>
> > On Mon, Oct 09, 2023 at 12:55:02PM +0200, Jakub Jelinek wrote:
> > > This makes wide_int unusable in GC structures, so for dwarf2out
> > > which was the only place which needed it there
On Mon, 9 Oct 2023, Jakub Jelinek wrote:
> On Mon, Oct 09, 2023 at 12:55:02PM +0200, Jakub Jelinek wrote:
> > This makes wide_int unusable in GC structures, so for dwarf2out
> > which was the only place which needed it there is a new rwide_int type
> > (restricted wide_int) which supports only up
On Mon, Oct 09, 2023 at 03:44:10PM +0200, Jakub Jelinek wrote:
> Thanks, just quick answers, will work on patch adjustments after trying to
> get rid of rwide_int (seems dwarf2out has very limited needs from it, just
> some routine to construct it in GCed memory (and never change afterwards)
> from
On Mon, Oct 09, 2023 at 12:55:02PM +0200, Jakub Jelinek wrote:
> This makes wide_int unusable in GC structures, so for dwarf2out
> which was the only place which needed it there is a new rwide_int type
> (restricted wide_int) which supports only up to RWIDE_INT_MAX_ELTS limbs
> inline and is trivia
On Mon, Oct 09, 2023 at 01:54:19PM +0100, Richard Sandiford wrote:
> > I've additionally built it with the incremental attached patch and
> > on make -C gcc check-gcc check-g++ -j32 -k it didn't show any
> > wide_int/widest_int heap allocations unless a > 128-bit _BitInt or wb/uwb
> > constant need
divmod_internal): Likewise.
> (wi::lshift_large): For len > WIDE_INT_MAX_INL_ELTS estimate
> it from xlen and skip.
> (rshift_large_common): Remove xprecision argument, add len
> argument with len computed in caller. Don't return anything.
>
ould identify other similar cases where the limit is
> known (statically) to be the current limit, rather than 65536.
>
> I think one of the worst things we could do is push the requirement
> up to users of the API to have one path for _BitInts and one for "normal"
> integ
ISION on
widest_int construction from wide_int/INTEGER_CST etc. wouldn't achieve
those goals. Grepping outside of wide-int.{cc,h} for widest_int, I see
around 450 matches, sure, that doesn't mean 450 places where we'd need to
add some guard to punt for the larger _BitInt (if it is pos
Just some off-the-cuff thoughts. Might think differently when
I've had more time...
Richard Biener writes:
> On Mon, 28 Aug 2023, Jakub Jelinek wrote:
>
>> Hi!
>>
>> While the _BitInt series isn't committed yet, I had a quick look at
>> lifting the current lowest limitation on maximum _BitInt p
On Mon, 28 Aug 2023, Jakub Jelinek wrote:
> Hi!
>
> While the _BitInt series isn't committed yet, I had a quick look at
> lifting the current lowest limitation on maximum _BitInt precision,
> that wide_int can only support wide_int until WIDE_INT_MAX_PRECISION - 1.
>
> Note, other limits if that
Hi!
While the _BitInt series isn't committed yet, I had a quick look at
lifting the current lowest limitation on maximum _BitInt precision,
that wide_int can only support wide_int until WIDE_INT_MAX_PRECISION - 1.
Note, other limits if that is lifted are INTEGER_CST currently using 3
unsigned cha
On Wed, 19 Jul 2023, Jakub Jelinek wrote:
> Hi!
>
> As the following testcase shows, wi::divmod_internal doesn't handle
> correctly signed division with precision > 64 when the dividend (and likely
> divisor as well) is the type's minimum and the precision isn't divisible
> by 64.
>
> A few line
Hi!
As the following testcase shows, wi::divmod_internal doesn't handle
correctly signed division with precision > 64 when the dividend (and likely
divisor as well) is the type's minimum and the precision isn't divisible
by 64.
A few lines above what the patch hunk changes is:
/* Make the divis
Sayle
>
> gcc/ChangeLog
> * simplify-rtx.cc (simplify_binary_operation_1) : Use wide-int
> instead of HWI_COMPUTABLE_MODE_P and UINTVAL in transformation of
> (and (extend X) C) as (zero_extend (and X C)), to also optimize
> modes wider than HOST_WIDE_INT.
>
>
> Thanks in advance,
> Roger
> --
>
heck, both with and without --target_board=unix{-m32}
with no new failures. Ok for mainline?
2023-05-23 Roger Sayle
gcc/ChangeLog
* simplify-rtx.cc (simplify_binary_operation_1) : Use wide-int
instead of HWI_COMPUTABLE_MODE_P and UINTVAL in transformation of
(and (exten
Hi!
When looking into _BitInt support, I've noticed unterminated parens in
a function comment.
Fixing thusly.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2023-05-17 Jakub Jelinek
* wide-int.cc (wi::from_array): Add missing closing paren in fu
On Tue, 9 May 2023, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because bitwise ccp2 handles
> a rotate with a signed type incorrectly.
> Seems tree-ssa-ccp.cc has the only callers of wi::[lr]rotate with 3
> arguments, all other callers just rotate in the right precision
Hi!
The following testcase is miscompiled, because bitwise ccp2 handles
a rotate with a signed type incorrectly.
Seems tree-ssa-ccp.cc has the only callers of wi::[lr]rotate with 3
arguments, all other callers just rotate in the right precision and
I think work correctly. ccp works with widest_in
On Mon, Apr 17, 2023 at 8:50 PM Aldy Hernandez via Gcc-patches
wrote:
>
>
>
> On 4/17/23 20:47, Andrew Pinski wrote:
> > On Mon, Apr 17, 2023 at 11:44 AM Aldy Hernandez via Gcc-patches
> > wrote:
> >>
> >> I'm about to add one more use of the same snippet of code, for a total
> >> of 4 identical
On 4/17/23 20:47, Andrew Pinski wrote:
On Mon, Apr 17, 2023 at 11:44 AM Aldy Hernandez via Gcc-patches
wrote:
I'm about to add one more use of the same snippet of code, for a total
of 4 identical calculations in the code base.
This seems safe enough even before the release, since this file
On Mon, Apr 17, 2023 at 11:44 AM Aldy Hernandez via Gcc-patches
wrote:
>
> I'm about to add one more use of the same snippet of code, for a total
> of 4 identical calculations in the code base.
>
> This seems safe enough even before the release, since this file hardly
> changes and I'm pretty much
I'm about to add one more use of the same snippet of code, for a total
of 4 identical calculations in the code base.
This seems safe enough even before the release, since this file hardly
changes and I'm pretty much the only one who's touched it this year.
OK for trunk?
gcc/ChangeLog:
*
Jakub Jelinek writes:
> Hi!
>
> As the following self-test testcase shows, wi::shifted_mask sometimes
> doesn't create canonicalized wide_ints, which then fail to compare equal
> to canonicalized wide_ints with the same value.
> In particular, wi::mask (128, false, 128) gives { -1 } with len 1 and
Hi!
As the following self-test testcase shows, wi::shifted_mask sometimes
doesn't create canonicalized wide_ints, which then fail to compare equal
to canonicalized wide_ints with the same value.
In particular, wi::mask (128, false, 128) gives { -1 } with len 1 and prec 128,
while wi::shifted_mask
he same job?)
The mpz use predates wide int and double int wasn't enough.
and when wi::to_mpz is called e.g. on the
>TYPE_MAX_VALUE of __uint128_t, it initializes the mpz_t result with
>wrong
>value.
>wi::to_mpz has code to handle negative wide_ints in signed types by
>inverting a
ecision when wi::neg_p.
E.g. the 0x TYPE_MAX_VALUE is represented
in wide_int as 0x len 1, and wi::to_mpz would create
0x mpz_t value from that.
This patch handles it by adding the needed -1 host wide int words (and has
also co
I fell over an ICE where wide_int_to_type_1's expectations of pointer
value caching didn't match that of cache_integer_cst's behaviour. I
don't know why it only exhibited on the modules branch, but it seems
pretty wrong. This patch matches up the behaviours and adds a comment
about that.
On Tue, Oct 27, 2020 at 05:46:42PM +, Richard Sandiford via Gcc wrote:
> >> and proceeds to call
> >>
> >> wide_int new_lb = wi::set_bit (r.lower_bound (0), 127)
> >>
> >> and creates the value:
> >>
> >> p new_lb
> >> { = {val = {-65535, -1, 0}, len = 2, precision = 128},
> >> static is_sig
On Thu, Jan 23, 2020 at 2:17 PM Jakub Jelinek wrote:
>
> On Thu, Jan 23, 2020 at 10:38:31AM +0100, Uros Bizjak wrote:
> > On Thu, Jan 23, 2020 at 10:33 AM Jakub Jelinek wrote:
> > >
> > > On Thu, Jan 23, 2020 at 09:14:42AM +, Richard Sandiford wrote:
> > > > > The other patch is something sug
On Thu, Jan 23, 2020 at 10:38:31AM +0100, Uros Bizjak wrote:
> On Thu, Jan 23, 2020 at 10:33 AM Jakub Jelinek wrote:
> >
> > On Thu, Jan 23, 2020 at 09:14:42AM +, Richard Sandiford wrote:
> > > > The other patch is something suggested by Richard S., avoid using OImode
> > > > for this and inst
On Thu, Jan 23, 2020 at 10:33 AM Jakub Jelinek wrote:
>
> On Thu, Jan 23, 2020 at 09:14:42AM +, Richard Sandiford wrote:
> > > The other patch is something suggested by Richard S., avoid using OImode
> > > for this and instead use a partial int mode that is smaller. This is
> > > still
> > >
On Thu, Jan 23, 2020 at 09:14:42AM +, Richard Sandiford wrote:
> > The other patch is something suggested by Richard S., avoid using OImode
> > for this and instead use a partial int mode that is smaller. This is still
> > playing with fire because even the partial int mode is larger than
> >
Jakub Jelinek writes:
> Hi!
>
> The following testcase ICEs, because during try_combine of i3:
> (insn 18 17 19 2 (parallel [
> (set (reg:CCO 17 flags)
> (eq:CCO (plus:OI (sign_extend:OI (reg:TI 96))
> (const_int 1 [0x1]))
> (
Hi!
The following testcase ICEs, because during try_combine of i3:
(insn 18 17 19 2 (parallel [
(set (reg:CCO 17 flags)
(eq:CCO (plus:OI (sign_extend:OI (reg:TI 96))
(const_int 1 [0x1]))
(sign_extend:OI (plus:TI (reg:TI 96)
On 11/06/2018 04:38 AM, Alexandre Oliva wrote:
Just like CONST_INT, CONST_WIDE_INT is VOIDmode, so LRA might be
tempted to build a SUBREG to "convert" it to the wanted mode. That's
no use. Test for CONST_SCALAR_INT_P instead of CONST_INT_P so that we
skip the subreg creation for both.
Regstrap
Just like CONST_INT, CONST_WIDE_INT is VOIDmode, so LRA might be
tempted to build a SUBREG to "convert" it to the wanted mode. That's
no use. Test for CONST_SCALAR_INT_P instead of CONST_INT_P so that we
skip the subreg creation for both.
Regstrapped on x86_64- and i686-linux-gnu. Ok to install
On Mon, Sep 3, 2018 at 8:58 AM Aldy Hernandez wrote:
>
>
Can you re-base and re-post please?
Sorry for being late here.
Richard.
>
> Forwarded Message
> Subject: Re: lightweight class to wide int ranges in VRP and friends
> Date: Fri, 24 Aug 2018 13:40:29
On 09/05/2018 10:57 AM, Michael Matz wrote:
Hi,
On Wed, 5 Sep 2018, Aldy Hernandez wrote:
No apologies needed. I welcome all masochists to join me in my personal hell
:).
;-)
How can this test and following code catch all problematic cases? Assume
a range of [253..257], truncating to
Hi,
On Wed, 5 Sep 2018, Aldy Hernandez wrote:
> No apologies needed. I welcome all masochists to join me in my personal hell
> :).
;-)
> > How can this test and following code catch all problematic cases? Assume
> > a range of [253..257], truncating to 8 bits unsigned. The size of the
> > ra
On 09/05/2018 08:58 AM, Michael Matz wrote:
Hi,
On Tue, 4 Sep 2018, Aldy Hernandez wrote:
to make the result ~[0, 5], is it? At least the original code dropped
that to VARYING. For the same reason truncating [3, 765] from
short to unsigned char isn't [3, 253]. But maybe I'm missing somet
Hi,
On Tue, 4 Sep 2018, Aldy Hernandez wrote:
> > to make the result ~[0, 5], is it? At least the original code dropped
> > that to VARYING. For the same reason truncating [3, 765] from
> > short to unsigned char isn't [3, 253]. But maybe I'm missing something.
Sorry for chiming in, but this
On 09/04/2018 10:20 AM, Richard Biener wrote:
On Tue, Sep 4, 2018 at 4:12 PM Aldy Hernandez wrote:
I honestly don't remember exactly but I suppose precision mismatched somehow.
Your code was OK with not using widest_ints.
Ah, this got lost in the noise. Sorry.
Will commit the original
dle
things generically and return varying when the range spans the entire
domain. It also keeps with the rest of the wide_int_range_* functions
that return false when we know it's going to be VR_VARYING.
Ah, OK, didn't know they did that. Not sure if that's convenient t
result ~[0, 5], is it? At least the original code dropped
> > that to VARYING. For the same reason truncating [3, 765] from
> > short to unsigned char isn't [3, 253]. But maybe I'm missing something.
>
> Correct, but in that case we will realize that in wide_int_range_co
int_range_* functions
that return false when we know it's going to be VR_VARYING.
Ah, OK, didn't know they did that. Not sure if that's convenient though
given VR_VARYING has no representation in the wide-int-range "range"
so callers chaining ops would need to do sth
RYING. For the same reason truncating [3, 765] from
short to unsigned char isn't [3, 253]. But maybe I'm missing something.
> >
> > + return (!wi::eq_p (min, wi::min_value (outer_prec, outer_sign))
> > + || !wi::eq_p (max, wi::max_value (
On 09/04/2018 07:58 AM, Richard Biener wrote:
On Mon, Sep 3, 2018 at 1:32 PM Aldy Hernandez wrote:
On 08/28/2018 05:27 AM, Richard Biener wrote:
On Mon, Aug 27, 2018 at 2:24 PM Aldy Hernandez wrote:
Howdy!
Phew, I think this is the last abstraction. This handles the unary
CONVERT_EX
On Mon, Sep 3, 2018 at 1:32 PM Aldy Hernandez wrote:
>
>
>
> On 08/28/2018 05:27 AM, Richard Biener wrote:
> > On Mon, Aug 27, 2018 at 2:24 PM Aldy Hernandez wrote:
> >>
> >> Howdy!
> >>
> >> Phew, I think this is the last abstraction. This handles the unary
> >> CONVERT_EXPR_P code.
> >>
> >> I
.
Tested on all languages on x86-64 Linux.
OK for trunk?
gcc/
* wide-int-range.cc (wide_int_range_convert): New.
* wide-int-range.h (wide_int_range_convert): New.
* tree-vrp.c (extract_range_from_unary_expr): Abstract wide int
code into wide_int_range_convert.
(extract_range_into_wide_
Forwarded Message
Subject: Re: lightweight class to wide int ranges in VRP and friends
Date: Fri, 24 Aug 2018 13:40:29 -0400
From: Aldy Hernandez
To: Richard Biener
CC: GCC Patches
On 08/24/2018 06:32 AM, Richard Biener wrote:
On Wed, Aug 15, 2018 at 7:31 PM Aldy
On 27 August 2018 14:24:33 CEST, Aldy Hernandez wrote:
>Howdy!
>
>Phew, I think this is the last abstraction. This handles the unary
>CONVERT_EXPR_P code.
+bool
+wide_int_range_convert_tree (tree &tmin, tree &tmax,
+tree outer_type,
+signo
On 08/28/2018 05:27 AM, Richard Biener wrote:
On Mon, Aug 27, 2018 at 2:24 PM Aldy Hernandez wrote:
Howdy!
Phew, I think this is the last abstraction. This handles the unary
CONVERT_EXPR_P code.
It's the usual story-- normalize the symbolics to [-MIN,+MAX] and handle
everything generical
On Mon, Aug 27, 2018 at 2:24 PM Aldy Hernandez wrote:
>
> Howdy!
>
> Phew, I think this is the last abstraction. This handles the unary
> CONVERT_EXPR_P code.
>
> It's the usual story-- normalize the symbolics to [-MIN,+MAX] and handle
> everything generically.
>
> Normalizing the symbolics broug
guages=all, because my past sins are still
haunting me.
OK?
gcc/
* wide-int-range.cc (wide_int_range_convert_tree): New.
* wide-int-range.h (wide_int_range_convert_tree): New.
* tree-vrp.c (extract_range_from_unary_expr): Abstract wide int
code into wide_int_range_co
. perform some wide int operation on the wide int range
4. convert back to a value range
So I've decided to clean this up even more. Instead of passing a pair
of wide ints plus sign, precision, and god knows what to every
wide_int_range_* function, I've implemented a lighweight class
(wi_
On Wed, Aug 15, 2018 at 7:31 PM Aldy Hernandez wrote:
>
> I kept seeing the same patterns over and over in all this re-factoring:
>
> 1. extract value_range constants into pairs of wide ints
>
> 2. mimic symbolics as [-MIN, +MAX] (most of the time :))
>
> 3. perform some w
On 08/20/2018 06:40 PM, Jeff Law wrote:
On 08/17/2018 01:11 AM, Aldy Hernandez wrote:
No change in functionality, just a straight up conversion.
OK for trunk?
curr.patch
gcc/
* wide-int-range.cc (wide_int_range_abs): New.
(wide_int_range_order_set): Rename from
On 08/17/2018 01:11 AM, Aldy Hernandez wrote:
> No change in functionality, just a straight up conversion.
>
> OK for trunk?
>
> curr.patch
>
>
> gcc/
>
> * wide-int-range.cc (wide_int_range_abs): New.
> (wide_int_range_order_set): R
No change in functionality, just a straight up conversion.
OK for trunk?
gcc/
* wide-int-range.cc (wide_int_range_abs): New.
(wide_int_range_order_set): Rename from wide_int_range_min_max.
* wide-int-range.h (wide_int_range_abs): New.
(wide_int_range_min_max): New.
* tree-vrp.c
I kept seeing the same patterns over and over in all this re-factoring:
1. extract value_range constants into pairs of wide ints
2. mimic symbolics as [-MIN, +MAX] (most of the time :))
3. perform some wide int operation on the wide int range
4. convert back to a value range
So I've de
On 08/02/2018 02:50 PM, Jeff Law wrote:
On 08/02/2018 12:23 PM, Aldy Hernandez wrote:
On 08/02/2018 02:07 PM, Jeff Law wrote:
On 08/01/2018 03:19 PM, David Malcolm wrote:
On Wed, 2018-08-01 at 15:39 -0400, Aldy Hernandez wrote:
This is actually an obvious patch, but I'm not committing it
nto an
inlined function in the header file.
Aldy
gcc/
* Makefile.in (wide-int-range.o): New.
* tree-vrp.c: Move all the wide_int_* functions to...
* wide-int-range.cc: ...here.
* tree-vrp.h: Move all the wide_int_* prototypes to...
* wide-int-range.h: ...here.
diff --git a/gcc/Makefile.in b/
On 08/02/2018 12:23 PM, Aldy Hernandez wrote:
>
>
> On 08/02/2018 02:07 PM, Jeff Law wrote:
>> On 08/01/2018 03:19 PM, David Malcolm wrote:
>>> On Wed, 2018-08-01 at 15:39 -0400, Aldy Hernandez wrote:
This is actually an obvious patch, but I'm not committing it just in
case you'd prefer
On 08/02/2018 02:07 PM, Jeff Law wrote:
On 08/01/2018 03:19 PM, David Malcolm wrote:
On Wed, 2018-08-01 at 15:39 -0400, Aldy Hernandez wrote:
This is actually an obvious patch, but I'm not committing it just in
case you'd prefer another name for the files.
BTW, is it our policy that new gc
On 08/01/2018 03:19 PM, David Malcolm wrote:
> On Wed, 2018-08-01 at 15:39 -0400, Aldy Hernandez wrote:
>> This is actually an obvious patch, but I'm not committing it just in
>> case you'd prefer another name for the files.
>
> BTW, is it our policy that new gcc C++ source files should have a .c
On Wed, 2018-08-01 at 15:39 -0400, Aldy Hernandez wrote:
> This is actually an obvious patch, but I'm not committing it just in
> case you'd prefer another name for the files.
BTW, is it our policy that new gcc C++ source files should have a .cc
extension?
> OK pending bootstrap?
>
> Aldy
This is actually an obvious patch, but I'm not committing it just in
case you'd prefer another name for the files.
OK pending bootstrap?
Aldy
gcc/
* Makefile.in (wide-int-range.o): New.
* tree-vrp.c: Move all the wide_int_* functions to...
* wide-int-range.c: ...here.
* tree-v
ging a lot easier.
>
> My next patch will move all the wide_int_range_* stuff into
> wide-int-range.[hc].
>
> I'm really liking how this is turning out, BTW: a *lot* cleaner, less
> code duplication, and shareable to boot :).
>
> OK pending one more round of tests?
Only coa
organized multiplication and lshifts for maximal sharing. This
also gets rid of some repetitive stuff.
I've also added a value_range::dump like wide_int::dump. It makes
debugging a lot easier.
My next patch will move all the wide_int_range_* stuff into
wide-int-range.[hc].
I'
k;
> > etc
> >
> > How do you suggest we indicate success/failure to the caller?
>
> Oh, ok. Exceptions? (eh...)
>
> Well, so I guess you can leave the signature as-is apart from turing
> the overflow
> result into a pointer.
Alternatively handle it like wi::sdi
On Fri, Jul 13, 2018 at 10:05 AM Aldy Hernandez wrote:
>
>
>
> On 07/13/2018 03:02 AM, Richard Biener wrote:
> > On Thu, Jul 12, 2018 at 10:12 AM Aldy Hernandez wrote:
>
> > So besides the general discussion about references/pointers for out
> > parameters
> > let's stay consistet within related
On 07/13/2018 03:02 AM, Richard Biener wrote:
On Thu, Jul 12, 2018 at 10:12 AM Aldy Hernandez wrote:
So besides the general discussion about references/pointers for out parameters
let's stay consistet within related APIs. This means wide_int_binop should
have a
wide_int
wide_int_binop (e
; >> I tried both, but inlining looked cleaner :). Done.
> >>
> >>>
> >>> What about mixed INTEGER_CST / poly_int constants? Shouldn't it
> >>> be
> >>>
> >>> if (neither-poly-nor-integer-cst (arg1 || arg2))
> >>&g
eturn NULL_TREE;
if (poly_int_tree (arg1) || poly_int_tree (arg2))
poly-int-stuff
else if (INTEGER_CST && INTEGER_CST)
wide-int-stuff
? I see that is a pre-existing issue but if you are at refactoring...
wi::to_poly_wide should handle INTEGER_CST operands just fine
e your tree_binop to int_cst_binop?
>>>> Or maybe inline it into int_const_binop, also sharing the force_fit_type ()
>>>> tail with poly_int_binop?
>>>
>>> I tried both, but inlining looked cleaner :). Done.
>>>
>>>>
>>>> What a
-stuff
else if (INTEGER_CST && INTEGER_CST)
wide-int-stuff
? I see that is a pre-existing issue but if you are at refactoring...
wi::to_poly_wide should handle INTEGER_CST operands just fine
I hope.
This aborted:
gcc_assert (NUM_POLY_INT_COEFFS != 1);
but even taking it out
mixed INTEGER_CST / poly_int constants? Shouldn't it
>> be
>>
>> if (neither-poly-nor-integer-cst (arg1 || arg2))
>> return NULL_TREE;
>>if (poly_int_tree (arg1) || poly_int_tree (arg2))
>> poly-int-stuff
>>else if (INTEGER_CST &
ype ()
> tail with poly_int_binop?
>
> What about mixed INTEGER_CST / poly_int constants? Shouldn't it
> be
>
> if (neither-poly-nor-integer-cst (arg1 || arg2))
> return NULL_TREE;
> if (poly_int_tree (arg1) || poly_int_tree (arg2))
> poly-int-stuff
&
:). Done.
What about mixed INTEGER_CST / poly_int constants? Shouldn't it
be
if (neither-poly-nor-integer-cst (arg1 || arg2))
return NULL_TREE;
if (poly_int_tree (arg1) || poly_int_tree (arg2))
poly-int-stuff
else if (INTEGER_CST && INTEGER_CST)
wide-int-stuff
1 - 100 of 1057 matches
Mail list logo
