Index: gcc/optabs.c
===
--- gcc/optabs.c(revision 201884)
+++ gcc/optabs.c(working copy)
@@ -867,7 +867,8 @@ expand_subword_shift (enum machine_mode
outof_input, const1_rtx, 0, unsignedp, methods);
if
cleaned up version of convert_modes that handles all constants in a
uniform manner.
This is clean on x86-64. Will test on other platforms tomorrow.
kenny
Index: gcc/expr.c
===
--- gcc/expr.c(revision 201884)
+++ gcc/expr.c
On 08/23/2013 11:02 AM, Richard Sandiford wrote:
Hi Kenny,
This is the first time I've looked at the implementation of wide-int.h
(rather than just looking at the rtl changes, which as you know I like
in general), so FWIW here are some comments on wide-int.h. I expect
a lot of them overlap with
On 08/24/2013 08:05 AM, Richard Sandiford wrote:
Richard Sandiford writes:
I wonder how easy it would be to restrict this use of "zero precision"
(i.e. flexible precision) to those where primitive types like "int" are
used as template arguments to operators, and require a precision when
constru
On 08/24/2013 02:16 PM, Florian Weimer wrote:
On 08/13/2013 10:57 PM, Kenneth Zadeck wrote:
1) The 4 files that hold the wide-int code itself. You have seen a
lot of this code before except for the infinite precision
templates. Also the classes are more C++ than C in their flavor
fixed with the enclosed patch.
On 08/23/2013 11:02 AM, Richard Sandiford wrote:
/* Return true if THIS is negative based on the interpretation of SGN.
For UNSIGNED, this is always false. This is correct even if
precision is 0. */
inline bool
wide_int::neg_p (signop sgn) const
It seems
The patch goes for (1) but (2) seems better to me, for a few reasons:
* As above, constants coming from rtl are already in the right form,
so if you create a wide_int from an rtx and only query it, no explicit
extension is needed.
* Things like logical operations and right shifts natur
On 08/25/2013 02:42 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 08/24/2013 08:05 AM, Richard Sandiford wrote:
Richard Sandiford writes:
I wonder how easy it would be to restrict this use of "zero precision"
(i.e. flexible precision) to those where primitive types like
cleaned up code to get around tree-vrp issue. added some code that
richard is going to play with to see how hard it would be to clean up
rtl constants.
kenny
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc (revision 201968)
+++ gc
On 08/25/2013 06:55 PM, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was needed to avoid cross-dependencies
between
fixed fits_uhwi_p.
tested on x86-64.
kenny
Index: gcc/wide-int.h
===
--- gcc/wide-int.h (revision 201985)
+++ gcc/wide-int.h (working copy)
@@ -1650,7 +1650,7 @@ wide_int_ro::fits_shwi_p () const
inline bool
wide_int_ro::fits_uhwi
removed all knowledge of SHIFT_COUNT_TRUNCATED from wide-int
both Richard Biener and Richard Sandiford had commented negatively about
this.
fixed bug with wide-int::fits_uhwi_p.
kenny
Index: gcc/fold-const.c
===
--- gcc/fold-co
you are about an hour behind in reading your email. I had just
committed a patch that is very close to this.
On 08/27/2013 02:31 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
fixed fits_uhwi_p.
tested on x86-64.
kenny
Index: gcc/wide-int.h
Removed the redundant implementations of several comparison function by
just forwarding the oo version to the static version. Added static
versions of cmp, cmpu and cmps.
kenny
Index: gcc/wide-int.h
===
--- gcc/wide-int.h (revisi
On 08/28/2013 03:45 AM, Richard Biener wrote:
On Tue, 27 Aug 2013, Kenneth Zadeck wrote:
removed all knowledge of SHIFT_COUNT_TRUNCATED from wide-int
both Richard Biener and Richard Sandiford had commented negatively about
this.
fixed bug with wide-int::fits_uhwi_p.
inline bool
On 08/28/2013 03:50 AM, Richard Biener wrote:
On Tue, 27 Aug 2013, Richard Sandiford wrote:
Kenneth Zadeck writes:
fixed fits_uhwi_p.
tested on x86-64.
kenny
Index: gcc/wide-int.h
===
--- gcc/wide-int.h (revision 201985
Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have random
bits.
Which is a red herring. It should be fixed. I cannot even believe
that sentenc
On 08/28/2013 12:45 PM, Mike Stump wrote:
On Aug 28, 2013, at 5:48 AM, Richard Biener wrote:
Only if the precision is > HOST_BITS_PER_WIDE_INT. If the precision
is HOST_BITS_PER_WIDE_INT then both are { -1U }.
That wasn't my understanding on how things work.
You are thinking about prec==0 nu
Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have random
bits.
Which is a red herring. It should be fixed. I cannot even believe
that sentenc
On 08/29/2013 04:42 AM, Richard Biener wrote:
On Wed, 28 Aug 2013, Kenneth Zadeck wrote:
Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have
On 08/28/2013 05:08 AM, Richard Biener wrote:
On Sun, 25 Aug 2013, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was n
Fixed
FAIL: gcc.dg/fixed-point/int-warning.c (test for warnings, line 12)
on
mips64-unknown-linux-gnu
Index: gcc/tree.c
===
--- gcc/tree.c (revision 202088)
+++ gcc/tree.c (working copy)
@@ -8531,11 +8531,11 @@ bool
int_fits_t
richi,
on further thought, this is going to be a huge task. The problem is at
the edges. right now we share the rep of the array with the tree-csts
and rtl (though the rtl sharing may go away to support canonization).
So if the hwi rep inside of wide int changes then we will have to
impl
My main discomfort is the double-int part. At this point in time the
only usage of double-int left on the branch is because the fixed ints
use it as their underlying representation. I think that rather than
doing a lot of work to accommodate this, it would be better to just
change the fixed r
On 09/02/2013 05:35 AM, Richard Biener wrote:
On Mon, 2 Sep 2013, Richard Sandiford wrote:
Kenneth Zadeck writes:
There is no place for exactly two HWIs in the machine independent parts
of the compiler,
I totally agree. In fact I was taking that so much for granted that
I didn't even
Richi, and the rest of the community,
Richard Sandiford has proposed a set of patches that change the wide-int
api in a significant way. We think that we really need some input from
the community as to if this is what we want using C++ in gcc is going to
look like. There are, as I see it, two
On 09/09/2013 09:56 AM, Richard Sandiford wrote:
Richard Biener writes:
On Mon, Sep 9, 2013 at 3:11 PM, Richard Sandiford
wrote:
Enabling the CONST_INT assert showed that this branch-local code was
passing the wrong mode to std::make_pair. The mode of X is OLDMODE,
and we're supposed to be c
i still have more testing to go on this but it seems to be ok.my
current problem is that the branch seems to have a fair number of
failures so i want to get that cleaned up before i do further testing
and commit this.
I left the old rtl constructor ifdefed out. We are likely to want them
Richi,
This patch canonizes the bits above the precision for wide ints with
types or modes that are not a perfect multiple of HOST_BITS_PER_WIDE_INT.
I expect that most of the changes in rtl.h will go away. in
particular, when we decide that we can depend on richard's patch to
clean up rtl
this is fine with me.
kenny
On 09/18/2013 03:27 AM, Richard Sandiford wrote:
Ping
Richard Sandiford writes:
Enabling the CONST_INT assert showed that this branch-local code was
passing the wrong mode to std::make_pair. The mode of X is OLDMODE,
and we're supposed to be converting it to MODE
this looks fine to me.
On 09/19/2013 02:56 PM, Richard Sandiford wrote:
It turns out that gcc20's version of binutils is too old for the LTO plugin,
so the tests I'd been running hadn't exercised it. This patch fixes a
regression that Kenny pointed out.
The problem was that build_int_cst and bu
Mike started a merge from trunk to the wide-int branch because the
previous merge had happened when bootstrap was broken for ppc.
This patch fixes mike's partial merge and has been bootstrapped and
tested on ppc. I will pull the patch down and test it on x86-64 tonight.
kenny
Index: gcc/post
On 09/24/2013 09:39 AM, Richard Biener wrote:
On Tue, 17 Sep 2013, Kenneth Zadeck wrote:
Richi,
This patch canonizes the bits above the precision for wide ints with types or
modes that are not a perfect multiple of HOST_BITS_PER_WIDE_INT.
I expect that most of the changes in rtl.h will go
On 09/24/2013 09:51 AM, Richard Biener wrote:
On Tue, 24 Sep 2013, Kenneth Zadeck wrote:
On 09/24/2013 09:39 AM, Richard Biener wrote:
On Tue, 17 Sep 2013, Kenneth Zadeck wrote:
Richi,
This patch canonizes the bits above the precision for wide ints with types
or
modes that are not a
chard Sandiford wrote:
Richard Biener writes:
On Tue, 24 Sep 2013, Kenneth Zadeck wrote:
On 09/24/2013 09:39 AM, Richard Biener wrote:
On Tue, 17 Sep 2013, Kenneth Zadeck wrote:
Richi,
This patch canonizes the bits above the precision for wide ints with types
or
modes that are not a perfect mul
out of that with really large numbers.
Of course you could have something else in mind.
kenny
On 10/03/2012 04:47 PM, Marc Glisse wrote:
On Wed, 3 Oct 2012, Kenneth Zadeck wrote:
The patch defines a new datatype, a 'wide_int' (defined in
wide-int.[ch], and this datatype will
been sacked".
However, it shows that you read the patch carefully, and i really
appreciate that. i owe you a beer (not that you need another at this
time of year).
Kenny
On 10/04/2012 08:48 AM, Richard Guenther wrote:
On Wed, Oct 3, 2012 at 7:15 PM, Kenneth Zadeck wrote:
The encl
ittle new to me, but given a perspective of the
rest of the compiler, this does not seem like the right way to go.
On Wed, 3 Oct 2012, Kenneth Zadeck wrote:
i have already converted the vrp code, so i have some guess at where
you are talking about. (of course correct me if i am wrong)
Actually richi, this code is "correct" for some broken definition of
correct.
If all that is done is to convert the rtl parts of the compiler, then
this code is the best you can do (of course an assertion that the length
is not greater than 2 would be a useful addition).
The code that is in
On 10/04/2012 12:58 PM, Richard Guenther wrote:
On Thu, Oct 4, 2012 at 3:55 PM, Kenneth Zadeck wrote:
Let me talk about the mode here first.
What this interface/patch provides is a facility where the constant math
that is done in optimizations is done exactly the way that it would be done
on
useful transformation
on any integer that would not fit in an int32.
However, this is your pass, and i understand the principal of "never
back down".
Kenny
On 10/04/2012 05:06 PM, Marc Glisse wrote:
On Wed, 3 Oct 2012, Kenneth Zadeck wrote:
i have already converted the vrp code, so i
richi,
let me address a bunch of issues that are randomly spread thru the thread.
1) unlike the double int's current relationship to int cst, we do not
currently wrap a wide-int into an CONST_WIDE_INT nor (in the patch that
you have not seen) do we wrap a wide-int into the int cst.wide-int
On 10/05/2012 10:36 AM, Richard Guenther wrote:
On Fri, Oct 5, 2012 at 4:14 PM, Richard Sandiford
wrote:
Richard Guenther writes:
On Fri, Oct 5, 2012 at 3:18 PM, Richard Sandiford
wrote:
Richard Sandiford writes:
How is CONST_WIDE_INT variable size?
It's just the usual trailing variable
richard s,
there are two comments that i deferred to you. that have the word
richard in them,
richi,
thank, i will start doing this now.
kenny
On 10/05/2012 09:49 AM, Richard Guenther wrote:
On Fri, Oct 5, 2012 at 2:39 PM, Richard Guenther
wrote:
Ok, I see where you are going. Let me loo
On 10/05/2012 01:29 PM, Richard Sandiford wrote:
+/* This is the maximal size of the buffer needed for dump. */
>>+const int MAX = (MAX_BITSIZE_MODE_ANY_INT / 4
>>++ MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_WIDE_INT + 32);
>>
>>I'd prefer a target macro for this, not anything ba
m the wide-int.h in the original patch at the
request of richi.
ok for commit?
Kenny
2012-10-5 Kenneth Zadeck
* hwint.h (HOST_BITS_PER_HALF_WIDE_INT, HOST_HALF_WIDE_INT,
HOST_HALF_WIDE_INT_PRINT, HOST_HALF_WIDE_INT_PRINT_C,
HOST_HALF_WIDE_INT
@@ -913,6 +945,7 @@ enum machine_mode\n{");
#endif
printf ("#define CONST_MODE_IBIT%s\n", adj_ibit ? "" : " const");
printf ("#define CONST_MODE_FBIT%s\n", adj_fbit ? "" : " const");
+ emit_max_int ();
puts ("\
\n\
#endif /* insn-modes.h */");
2012-10-5 Kenneth Zadeck
* genmodes.c (emit_max_int): New function.
(emit_insn_modes_h): Added call to emit_max_function.
This is the third patch in the series of patches to fix constant math.
this one changes some predicates at the rtl level to use the new
predicate CONST_SCALAR_INT_P.
I did not include a few that were tightly intertwined with other changes.
Not all of these changes are strictly mechanical. Ric
On 10/07/2012 08:47 AM, Richard Guenther wrote:
len seems redundant unless you want to optimize encoding.
>>len == (precision + HOST_BITS_PER_WIDE_INT - 1) / HOST_BITS_PER_WIDE_INT.
>
>that is exactly what we do. However, we are optimizing time, not space.
>the value is always stored in compr
On 10/07/2012 09:19 AM, Richard Guenther wrote:
>In fact, you could argue that the tree level did it wrong (not that i am
>suggesting to change this). But it makes me think what was going on when
>the decision to make TYPE_PRECISION be an INT_CST rather than just a HWI was
>made. For that th
yes, my bad. here it is with the patches.
On 10/06/2012 11:55 AM, Kenneth Zadeck wrote:
This is the third patch in the series of patches to fix constant math.
this one changes some predicates at the rtl level to use the new
predicate CONST_SCALAR_INT_P.
I did not include a few that were
is this ok to commit with this change?
kenny
On 10/05/2012 08:14 PM, Joseph S. Myers wrote:
On Fri, 5 Oct 2012, Kenneth Zadeck wrote:
+# define HOST_HALF_WIDE_INT_PRINT "h"
This may cause problems on hosts not supporting %hd (MinGW?), and there's
no real need for using &qu
On 10/18/2012 06:22 AM, Richard Biener wrote:
On Wed, Oct 17, 2012 at 11:47 PM, Kenneth Zadeck
wrote:
Richi,
I apologize for the size of this patch, but it only does one very small
thing, it is just that it does it all over the middle end.
This patch introduces a new api for extracting a
you know richi, i did not know who i was actually talking to. i said
who is this richard beiner person and then i saw the email address.
On 10/18/2012 08:58 AM, Richard Biener wrote:
On Thu, Oct 18, 2012 at 2:52 PM, Kenneth Zadeck
wrote:
On 10/18/2012 06:22 AM, Richard Biener wrote:
On
struct GTY(()) tree_int_cst {
struct tree_typed typed;
double_int int_cst;
@@ -5689,6 +5677,9 @@ extern const_tree strip_invariant_refs (const_tree);
extern tree lhd_gcc_personality (void);
extern void assign_assembler_name_if_neeeded (tree);
extern void warn_deprecated_use (tree, tree);
+
On 10/19/2012 04:22 AM, Richard Biener wrote:
On Thu, Oct 18, 2012 at 7:32 PM, Kenneth Zadeck
wrote:
This patch replaces all instances of INT_CST_LT and INT_CST_LT_UNSIGNED
with
the new functions tree_int_cst_lts_p and tree_int_cst_ltu_p. With the new
implementation of int_cst these
On 10/19/2012 07:13 AM, Richard Biener wrote:
On Fri, Oct 19, 2012 at 12:59 PM, Kenneth Zadeck
wrote:
On 10/19/2012 04:22 AM, Richard Biener wrote:
On Thu, Oct 18, 2012 at 7:32 PM, Kenneth Zadeck
wrote:
This patch replaces all instances of INT_CST_LT and INT_CST_LT_UNSIGNED
with
the new
On 10/19/2012 07:58 AM, Richard Biener wrote:
On Fri, Oct 19, 2012 at 1:49 PM, Kenneth Zadeck
wrote:
On 10/19/2012 07:13 AM, Richard Biener wrote:
On Fri, Oct 19, 2012 at 12:59 PM, Kenneth Zadeck
wrote:
On 10/19/2012 04:22 AM, Richard Biener wrote:
On Thu, Oct 18, 2012 at 7:32 PM, Kenneth
On 10/23/2012 10:12 AM, Richard Biener wrote:
On Tue, Oct 9, 2012 at 5:09 PM, Kenneth Zadeck wrote:
This patch implements the wide-int class.this is a more general version
of the double-int class and is meant to be the eventual replacement for that
class.The use of this class removes
On 10/23/2012 02:38 PM, Lawrence Crowl wrote:
On 10/23/12, Kenneth Zadeck wrote:
On 10/23/2012 10:12 AM, Richard Biener wrote:
+ inline bool minus_one_p () const;
+ inline bool zero_p () const;
+ inline bool one_p () const;
+ inline bool neg_p () const;
what's wrong with w == -1, w
On 10/23/2012 04:25 PM, Lawrence Crowl wrote:
On 10/23/12, Kenneth Zadeck wrote:
On 10/23/2012 02:38 PM, Lawrence Crowl wrote:
On 10/23/12, Kenneth Zadeck wrote:
On 10/23/2012 10:12 AM, Richard Biener wrote:
+ inline bool minus_one_p () const;
+ inline bool zero_p () const;
+ inline
On 10/25/2012 06:42 AM, Richard Biener wrote:
On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump wrote:
On Oct 24, 2012, at 2:43 AM, Richard Biener wrote:
On Tue, Oct 23, 2012 at 6:12 PM, Kenneth Zadeck
wrote:
On 10/23/2012 10:12 AM, Richard Biener wrote:
+ HOST_WIDE_INT val[2
jakub,
i am hoping to get the rest of my wide integer conversion posted by nov
5. I am under some adverse conditions here: hurricane sandy hit her
pretty badly. my house is hooked up to a small generator, and no one
has any power for miles around.
So far richi has promised to review them.
wait is because you
really do not like the fact these patches get rid of double in and that
style of programming and putting off that day serves no one well.
kenny
On 10/31/2012 05:59 AM, Richard Sandiford wrote:
Richard Biener writes:
On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck
On 10/31/2012 08:11 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
Richard Biener writes:
On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
wrote:
On 10/25/2012 06:42
level constant
propagators that require infinite precision so he is really the person
who both should know about this and generate proper tests.
kenny
On 10/31/2012 09:55 AM, Jakub Jelinek wrote:
On Wed, Oct 31, 2012 at 09:44:50AM -0400, Kenneth Zadeck wrote:
The tree-vpn uses an infinite
On 10/31/2012 10:05 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 2:54 PM, Kenneth Zadeck
wrote:
On 10/31/2012 08:11 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote
On 10/31/2012 09:54 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 2:30 PM, Richard Sandiford
wrote:
Richard Biener writes:
But that means that wide_int has to model a P-bit operation as a
"normal" len*HOST_WIDE_INT operation and then fix up the result
after the fact, which seems unnecess
On 10/31/2012 10:24 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 3:18 PM, Kenneth Zadeck
wrote:
On 10/31/2012 10:05 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 2:54 PM, Kenneth Zadeck
wrote:
On 10/31/2012 08:11 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Richard
writes:
On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
wrote:
On 10/25/2012 06:42 AM, Richard Biener wrote:
On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump
wrote:
On Oct 24, 2012, at 2:43 AM, Richard Biener
wrote:
On Tue, Oct 23, 2012 at 6:12 PM, Kenneth Zadeck
wrote:
On 10/23/2012 10:12 AM
Jelinek wrote:
On Wed, Oct 31, 2012 at 10:04:58AM -0400, Kenneth Zadeck wrote:
if one looks at where intel is going, they are doing exactly the
same thing.The difference is that they like to add the
operations one at a time rather than just do a clean implementation
like we did. Soon they will
On 10/31/2012 09:30 AM, Richard Sandiford wrote:
Richard Biener writes:
But that means that wide_int has to model a P-bit operation as a
"normal" len*HOST_WIDE_INT operation and then fix up the result
after the fact, which seems unnecessarily convoluted.
It does that right now. The operation
Jakub,
it is hard from all of the threads to actually distill what the real
issues are here. So let me start from a clean slate and state them simply.
Richi has three primary objections:
1) that we can do all of this with a templated version of double-int.
2) that we should not be passing in
Richard and others,
This patch changes the way that unsigned trees are canonicalized. As
with the last patch, I think that this patch is not that much of a step
forward. While it is still true that the signed tree-csts match the
representation of wide-ints, unsigned tree-csts do not and requ
On 10/03/2013 10:29 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
+ /* Got to be careful of precision 0 values. */
+ if (precision)
+len = MIN (len, max_len);
+ if (TYPE_SIGN (TREE_TYPE (x)) == UNSIGNED)
{
- if (precision < HOST_BITS_PER_WIDE_INT
- &&
I was thinking that we should always be able to use the constant as-is
for max_wide_int-based and addr_wide_int-based operations. The small_prec
again, you can get edge cased to death here.i think it would work
for max because that really is bigger than anything else, but it is
possible (t
So here is a patch with the change. As before, bootstrapped an tested on
x86-64.
On 10/03/2013 12:16 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
Changing the representation of unsigned constants is only worthwhile
if we can avoid the force_to_size for some unsigned cases. I think we
On 10/04/2013 01:00 PM, Richard Sandiford wrote:
I was hoping Richard would weigh in here. In case not...
Kenneth Zadeck writes:
I was thinking that we should always be able to use the constant as-is
for max_wide_int-based and addr_wide_int-based operations. The small_prec
again, you can
i added the assertion that richard requested and tested this on x86-64.
committed as revision 203602.
On 10/06/2013 05:13 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 10/04/2013 01:00 PM, Richard Sandiford wrote:
I was hoping Richard would weigh in here. In case not...
Kenneth
On 10/16/2013 09:55 AM, Richard Biener wrote:
Speaking in terms of a patch:
Index: tree.h
===
--- tree.h (revision 203690)
+++ tree.h (working copy)
@@ -5184,14 +5184,11 @@ wi::int_traits ::decompose (
This patch makes the PPC the first public target to use the
CONST_WIDE_INT representation rather than CONST_DOUBLES to represent
larger integers. There are two parts to this patch. The changes to
genrecog.c represent fixes that would be needed for any port that
supports CONST_WIDE_INTS and
On 10/16/2013 02:45 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
I note that we immediately return in the above case, so
if (precision < xprecision + HOST_BITS_PER_WIDE_INT)
{
len = wi::force_to_size (scratch, val, len, xprecision,
precision, UNSIG
On 10/15/2013 02:30 PM, Richard Sandiford wrote:
Richard Sandiford writes:
if (small_prec)
;
else if (precision == xprecision)
while (len >= 0 && val[len - 1] == -1)
len--;
Err, len > 0 obviously.
you were only close.patch tested on ppc and commit
On 10/17/2013 04:46 AM, Richard Biener wrote:
the case actually comes up on the ppc because they do a lot of 128 bit
math.I think i got thru the x86-64 without noticing this.
Well, it'd be suspicious if we're directly using 128-bit numbers
in addr_wide_int. The justification for the asserti
On 10/17/2013 07:49 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 04:46 AM, Richard Biener wrote:
the case actually comes up on the ppc because they do a lot of 128 bit
math.I think i got thru the x86-64 without noticing this.
Well, it'd be suspi
On 10/17/2013 08:29 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occupies a whole number of HWIs.
The tree representation of an unsigned 0x80
On 10/17/2013 07:30 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Kenneth Zadeck writes:
As mentioned in my message yesterday, I thought your new way of canonising
unsigned tree constants meant
On 10/17/2013 09:16 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 08:29 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
The new tree representation can have a length greater than max_len
for an unsigned
On 10/17/2013 09:48 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occ
On 10/17/2013 10:05 AM, Richard Sandiford wrote:
Richard Biener writes:
What's the reason again to not use my original proposed encoding
of the MSB being the sign bit? RTL constants simply are all signed
then. Just you have to also sign-extend in functions like lts_p
as not all constants are
On 10/18/2013 04:45 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Mike Stump wrote:
On Oct 17, 2013, at 1:46 AM, Richard Biener wrote:
[This function shows another optimization issue:
case BOOLEAN_TYPE:
/* Cache false or true. */
limit = 2;
if (wi::leu_p (cst, 1))
Richi,
Do you want me to back out the patch that changes the rep for unsigned
tree-csts?
kenny
On 10/19/2013 05:01 AM, Richard Sandiford wrote:
Mike Stump writes:
+ // We optimize x < y, where y is 64 or fewer bits.
+ // We have to be careful to not allow comparison to a large positive
+ // unsigned value like 0x8000, those would be encoded
+ // with a y.len == 2.
+ if (
On 10/19/2013 02:41 PM, Mike Stump wrote:
On Oct 19, 2013, at 7:22 AM, Richard Sandiford
wrote:
As discussed, this patch effectively goes back to your original idea of
having excess upper bits in a HWI being undefined on read (at least as
the default assumption). wide_int itself still ensures
On 10/19/2013 10:18 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 10/19/2013 05:01 AM, Richard Sandiford wrote:
Mike Stump writes:
+ // We optimize x < y, where y is 64 or fewer bits.
+ // We have to be careful to not allow comparison to a large positive
+ // unsigned value l
On 10/20/2013 06:30 AM, Richard Sandiford wrote:
If yesterday's patch goes in, we'll only need the scratch array for
HWI inputs. We can therefore shrink it to 2 HWIs.
Tested on x86_64-linux-gnu. OK for wide-int?
Thanks,
Richard
Index: gcc/wide-int.h
=
On 10/23/2013 08:13 AM, Richard Biener wrote:
On Wed, 23 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
The patch does that by adding:
wi::address (t)
for when we want to extend tree t to addr_wide_int precision and:
wi::extend (t)
for when we want to extend it to max_wid
On 10/29/2013 08:43 AM, Richard Sandiford wrote:
Richard Biener writes:
On Sun, 27 Oct 2013, Richard Sandiford wrote:
This patch adds some more optimisations to the wi:: comparison functions.
It uses the:
#define CONSTANT(X) (__builtin_constant_p (X) && (X))
idiom that was mentioned befor
On 10/29/2013 06:37 PM, Richard Sandiford wrote:
This patch tries to update the main wide_int comment to reflect the current
implementation.
- bitsizetype is TImode on x86_64 and others, so I don't think it's
necessarily true that all offset_ints are signed. (widest_int are
though.)
i am
On 10/29/2013 08:43 AM, Richard Sandiford wrote:
Richard Biener writes:
On Sun, 27 Oct 2013, Richard Sandiford wrote:
This patch adds some more optimisations to the wi:: comparison functions.
It uses the:
#define CONSTANT(X) (__builtin_constant_p (X) && (X))
idiom that was mentioned befor
1 - 100 of 350 matches
Mail list logo
