Kenneth Zadeck <zad...@naturalbridge.com> writes:
> I doubt that this list is comprehensive.
Hmm? It was supposed to be one target for each CPU, so if you think
I've missed one, please point it out. It certainly wasn't supposed
to be every target triple that gcc supports.
Even one target per CPU was useful, since quite a few wouldn't compile.
> When i many of these things a long time ago, I was not that interested
> in bit for bit compatibly as long as was never introducing any
> problems. in some cases it would have been hard to replicate some of
> the end cases with the wide-int code.
Not sure what you mean. The point was that if wide-int made things better,
we should just say "good" and move on. Which is why I'm not trying to
get bit-for-bit compatibility in the testcases I pointed out. But for
a change of this size I think we should at least know why any differences
occur.
Thanks,
Richard
> On 11/07/2013 12:51 PM, Richard Sandiford wrote:
>> I wanted to make sure that each backend still builds with wide-int and that
>> there weren't any unexplained changes in assembly output. I arbitrarily
>> picked one target for each CPU:
>>
>> aarch64-linux-gnueabi alpha-linux-gnu arc-elf arm-linux-gnueabi
>> avr-rtems bfin-elf c6x-elf cr16-elf cris-elf epiphany-elf
>> fr30-elf frv-linux-gnu h8300-elf ia64-linux-gnu iq2000-elf
>> lm32-elf m32c-elf m32r-elf m68k-linux-gnu mcore-elf mep-elf
>> microblaze-elf mips-linux-gnu mmix mn10300-elf moxie-elf
>> msp430-elf nds32le-elf hppa64-hp-hpux11.23 pdp11 picochip-elf
>> powerpc-linux-gnu powerpc-eabispe rl78-elf rx-elf s390-linux-gnu
>> score-elf sh-linux-gnu sparc-linux-gnu spu-elf tilegx-elf
>> tilepro-elf xstormy16-elf v850-elf vax-netbsdelf xtensa-elf
>> x86_64-darwin
>>
>> and built gcc and g++ from both the merge point and the wide-int branch.
>> The branch included the patches I've posted and a local change
>> to put CONST_WIDE_INT at the end of rtl.def (just for comparison,
>> as mentioned before). I then compiled gcc.c-torture, gcc.dg and g++.dg
>> at -O2 and compared the asm output. This obviously isn't a very strong
>> test, since none of the libraries are built, and since some of the test
>> cases rely on system headers, but it should at least be better than nothing.
>>
>> pdp11 and picochip-elf don't build on mainline due to:
>>
>> gcc/target-def.h:69:34: error: ‘default_stabs_asm_out_destructor’ was
>> not declared in this scope
>> # define TARGET_ASM_DESTRUCTOR default_stabs_asm_out_destructor
>>
>> Both the merge point and the branch built the other targets and there were
>> no new warnings on the branch. The only asm differences were in:
>>
>> * gcc.dg/fixed-point/const-1.s on targets that support it
>>
>> I think this is a known improvement. The test case checks a series of
>> conversions to make sure that the out-of-range ones produce a warning.
>> E.g.:
>>
>> short _Fract sfF = 1.0; /* { dg-warning "overflow" } */
>>
>> The asm differences are in the values produced for these out-of-range
>> casees. The old code used real_to_integer2, which saturates the result
>> to double_int precision. It then uses the fractional part of that result
>> to initialise sfF. The result therefore depends on the host (at least
>> in the general case).
>>
>> The new code instead saturates to the precision of the result, just like
>> we already do for:
>>
>> signed short s = 32768.0f;
>>
>> So this seems like a good change.
>>
>> * gcc.dg/vect/pr51799.c on m32c-elf and
>> * gcc.c-torture/execute/divconst-2.c on xstormy16-elf
>>
>> These are cases where wide-int converts a narrower-than-HWI
>> multiplication by 1 << (GET_MODE_PRECISION - 1) into a shift but
>> mainline doesn't. The mainline code looks like:
>>
>> /* Convert multiply by constant power of two into shift unless
>> we are still generating RTL. This test is a kludge. */
>> if (CONST_INT_P (trueop1)
>> && (val = exact_log2 (UINTVAL (trueop1))) >= 0
>> /* If the mode is larger than the host word size, and the
>> uppermost bit is set, then this isn't a power of two due
>> to implicit sign extension. */
>> && (width <= HOST_BITS_PER_WIDE_INT
>> || val != HOST_BITS_PER_WIDE_INT - 1))
>> return simplify_gen_binary (ASHIFT, mode, op0, GEN_INT (val));
>>
>> and this exact_log2 doesn't cope properly with the sign-extended
>> 0xff....8000... CONST_INT. The wide-int code is:
>>
>> /* Convert multiply by constant power of two into shift. */
>> if (CONST_SCALAR_INT_P (trueop1))
>> {
>> val = wi::exact_log2 (std::make_pair (trueop1, mode));
>> if (val >= 0 && val < GET_MODE_BITSIZE (mode))
>> return simplify_gen_binary (ASHIFT, mode, op0, GEN_INT (val));
>> }
>>
>> So this too seems like a good thing.
>>
>> Thanks,
>> Richard
