On 11/26/2013 09:12 AM, Richard Biener wrote:
On Tue, Nov 26, 2013 at 3:00 PM, Kenneth Zadeck
<zad...@naturalbridge.com> wrote:
On 11/26/2013 08:44 AM, Richard Earnshaw wrote:
On 26/11/13 09:18, Eric Botcazou wrote:
you are correct - this was an incorrect change. I believe that the
patch below would be correct, but it is impossible to test it because (i
believe) that gcc no longer works if the host_bits_per_wide_int is 32.
I could be wrong about this but if i am correct, what do you want me to
do?
While you're right that most mainstream architectures now require a
64-bit
HWI, not all of them do according to config.gcc, so I don't think that
this
path is entirely dead yet. I'll carry out the testing once we agree on
the
final change.
I'm hoping, once this patch series is in that we might be able to
migrate the ARM port back to supporting a 32-bit HWI. The driving
factor behind the original switch was supporting 128-bit constants for
Neon and these patches should resolve that.
R.
Richard,
I had not realized that you were into self abuse like that. you are
going to have a bad time. I tried this as a way to test the wide-int branch
because if we made hwi be 32bits, then it would trigger the long version of
the implementation wide-int routines. What a disaster!!!! richard sandiford
told me not to try and i ignored him. that was a wasted weekend!!! There
are roadblocks everywhere. i certainly do not have a complete list,
because i gave up after hacking a few things back. But very quickly you
find places like real.[ch] which no longer work because the math that the
dfp people hacked into it no longer works if the hwis are 32 bits. it is
misleading because all of the tests are still there, it is just that the
equations return the wrong answers. It is like this, one place after
another.
As far as your hope that once this patch goes in you would be able to
support 128 bit constants is only partially true. it will/should be the
case, that you always get the correct answer and the code will not ice.
That is the good news. But the bad news is that there is still way to
much code of the form, if var fits in hwi, do some optimization, else do not
do the optimization. Richi did not want me to attack this code yet because
it would have made the patches even bigger. For the rtl level a lot of
this was removed because i did it before he told me not to, but the tree
level still has tons of code like this. So at least for a long time, like
the close of the next release, this is not going to get fixed.
Note that in the long run we want wide-int to use HOST_WIDEST_FAST_INT
and not HOST_WIDE_INT internally. I know I asked you to do that
but it's of course too late now.
Richard.
i started to do it and it turned out to be harder than either of us
thought it would. As i remember it, the problem came up of what were
you going to populate the tree_csts and const_wide_ints. I assume that
you wanted those to have HWFI in them also. Then i started looking at
the *fits_*hwi to_*hwi which is used in a billion places and that was
now starting to look expensive.
perhaps this change could/should be done later after there are almost no
calls to these functions. But while there are still a billion of them
in the code, this seemed like a mistake.
Kenny
