On Nov 19, 2014, at 4:24 AM, Richard Biener <rguent...@suse.de> wrote: > On Wed, 19 Nov 2014, Jakub Jelinek wrote: >> For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure >> about TARGET_SUPPORTS_WIDE_INT != 0, can it express any generic_wide_int, or >> is it still bound to wide_int (i.e. MAX_BITSIZE_MODE_ANY_INT rounded up) >> precision? Mike? > > It can represent any - well, the RTX at least. Code then using > "simple" wide_int may wreck then though.
So, my worry is this… once you start in on adding support here or there for int modes wider than the largest supported int mode, you create a never ending maintenance nightmare with complex rules that one will never be able to keep straight. There needs to be a single line or two, that explains the rules that we all agree to, then it will always be clear what the rule is. The largest supported int mode is: x, has a nice, simple, easy to explain aspect to it. If one looks at the rtl optimization code, and all the code that cracks rtl integer constants and plays with them, I don’t think _all_ that code is larger than max safe. I have reason to believe it is all reasonable safe up to the max however; that was our contribution in wide-int. Originally I was going to say, this patch needs a int larger than MAX_BITSIZE_MODE_ANY_INT person to review it, meaning, that isn’t me. It still isn’t me; so, I defer that to someone that wants to try and keep those rules straight and memorize them and ensure the totality of the compiler actually works for theses cases by design. Luckily, that only affects x86, as it is the only port to try and slice and dice like this. So, I’ll defer to others on that.
