Re: Need help with PR71976 combine.c::get_last_value returns a wrong result
On 25.07.2016 23:05, Segher Boessenkool wrote:
On Mon, Jul 25, 2016 at 02:28:28PM +0200, Georg-Johann Lay wrote:
(insn 43 31 44 2 (set (reg:QI 18 r18)
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 51 50 52 2 (set (reg:QI 16 r16)
(const_int 40 [0x28])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 52 51 61 2 (set (reg:DI 18 r18)
(ashiftrt:DI (reg:DI 18 r18)
(reg:QI 16 r16))) bug-combin.c:29 1417 {ashrdi3_insn}
(expr_list:REG_DEAD (reg:QI 16 r16)
(nil)))
/* An arithmetic right shift of a quantity known to be -1 or 0
is a no-op. */
if (code == ASHIFTRT
&& (num_sign_bit_copies (varop, shift_mode)
== GET_MODE_PRECISION (shift_mode)))
{
count = 0;
break;
}
num_sign_bit_copies() eventually calls
combine.c::reg_num_sign_bit_copies_for_combine()
which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx.
Total outcome is that the right shift of reg:DI 18 is transformed to a
no-op move and cancelled out in the remainder.
Why does num_sign_bit_copies return something bigger than 8?
Because it thinks the last value was const0_rtx (which is incorrect) and hence
thinks a shift of a reg that's always 0 is the same as a no-op move of the reg
to itself.
The problem might be that get_last_value() is called for reg:DI 18 and
combine's internal bookkeeping is incorrect
struct reg_stat_type {
/* Record last point of death of (hard or pseudo) register n. */
rtx_insn *last_death;
/* Record last point of modification of (hard or pseudo) register n. */
rtx_insn *last_set;
.last_set is the set for reg:QI 18 but later insns also change hard reg:DI 18,
for example the set of reg:QI 19. This means that the information in
reg_stat_type does not tell the whole story for hard regs.
One fix could be to get the mode precision of the SET from the last_set insn
and only use the information if that mode is at least as wide as the mode of
the register for which get_last_value is called. reg_stat_type has
.last_set_mode for this purpose (QImode in the test case).
IIUC get_last_value should return 0 in this case?
/* If we don't have a value, or if it isn't for this basic block and
it's either a hard register, set more than once, or it's a live
at the beginning of the function, return 0.
We do have a value, and it is for this bb.
But not for the complete hard register; it's only for reg:QI 18 which is one
byte of reg:DI 18, thus the code should never reach this point in the first
place and return earlier. For example:
Index: combine.c
===
--- combine.c (revision 238701)
+++ combine.c (working copy)
@@ -13206,6 +13206,13 @@ get_last_value (const_rtx x)
&& DF_INSN_LUID (rsp->last_set) >= subst_low_luid)
return 0;
+ /* If the lookup is for a hard register make sure that value contains at
least
+ as many bits as x does. */
+
+ if (regno < FIRST_PSEUDO_REGISTER
+ && GET_MODE_PRECISION (rsp->last_set_mode) < GET_MODE_PRECISION
(GET_MODE (x)))
+return 0;
+
/* If the value has all its registers valid, return it. */
if (get_last_value_validate (&value, rsp->last_set, rsp->last_set_label, 0))
return value;
Johann
Segher
GCC 4.9.4 Status Report (2016-07-26), branch frozen for release
The 4.9 branch is now frozen for the final GCC 4.9.4 release, I will announce GCC 4.9.4 RC1 once it has built. Richard.
Re: Need help with PR71976 combine.c::get_last_value returns a wrong result
On Tue, Jul 26, 2016 at 02:14:49PM +0200, Georg-Johann Lay wrote:
> >>which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx.
> >>Total outcome is that the right shift of reg:DI 18 is transformed to a
> >>no-op move and cancelled out in the remainder.
> >
> >Why does num_sign_bit_copies return something bigger than 8?
>
> Because it thinks the last value was const0_rtx (which is incorrect) and
Why is that incorrect? See insn 43. Is there another insn I missed?
> The problem might be that get_last_value() is called for reg:DI 18 and
> combine's internal bookkeeping is incorrect
>
> struct reg_stat_type {
> /* Record last point of death of (hard or pseudo) register n. */
> rtx_insn*last_death;
>
> /* Record last point of modification of (hard or pseudo) register n. */
> rtx_insn*last_set;
>
> .last_set is the set for reg:QI 18 but later insns also change hard reg:DI
> 18, for example the set of reg:QI 19. This means that the information in
> reg_stat_type does not tell the whole story for hard regs.
>
> One fix could be to get the mode precision of the SET from the last_set
> insn and only use the information if that mode is at least as wide as the
> mode of the register for which get_last_value is called. reg_stat_type has
> .last_set_mode for this purpose (QImode in the test case).
Yes, last_set_mode, and there is last_set_sign_bit_copies too. Are those
correct?
> >We do have a value, and it is for this bb.
>
> But not for the complete hard register; it's only for reg:QI 18 which is
> one byte of reg:DI 18,
The rest of the hard register bits are set to unspecified values.
> thus the code should never reach this point in the
> first place and return earlier. For example:
>
> Index: combine.c
> ===
> --- combine.c (revision 238701)
> +++ combine.c (working copy)
> @@ -13206,6 +13206,13 @@ get_last_value (const_rtx x)
>&& DF_INSN_LUID (rsp->last_set) >= subst_low_luid)
> return 0;
>
> + /* If the lookup is for a hard register make sure that value contains at
> least
> + as many bits as x does. */
> +
> + if (regno < FIRST_PSEUDO_REGISTER
> + && GET_MODE_PRECISION (rsp->last_set_mode) < GET_MODE_PRECISION
> (GET_MODE (x)))
> +return 0;
> +
>/* If the value has all its registers valid, return it. */
>if (get_last_value_validate (&value, rsp->last_set, rsp->last_set_label,
>0))
> return value;
That might be a bit harsh.
First things first: is the information recorded correct?
Segher
Two suggestions for gcc C compiler to extend C language (by WD Smith)
1. Gcc with stdint.h already provides such nice predefined types as uint8_t. Sizes provided are 8,16,32, and 64. In some sense uint1_t is available too (stdbool.h) but at least on my machine stdbool uses 8-bits to store a bool, e.g. an array of 1000 bools takes 8000 bits, which is asinine and kind of defeats the point. I suggest adding uint1_t, uint2_t and uint4_t support to gcc, and packed. 128 would be nice too. It is obnoxious and arbitrary that only 8,16,32,64 are available, and it is a pain to make programmers continually have to reinvent the wheel to implement packed nybbles, etc -- and even when I do so, then my implementation results in ugly code, different than the nice-looking code for packed bytes. Why not allow me to write uniform code? Why not catch up to freaking PASCAL from 40 years ago, which already provided packed arrays? This ought to be pretty trivial given that you already did 8,16,32,64 to do 1,2,4 also. 2. Gcc already provides a way to produce quotient and remainder simultaneously, producing a struct with two fields as output: div_t x = div(a,b); causes x.quot = a/b, x.rem = a%b. Not a lot of people know gcc provides that, but it does, and that is good, because it provides access to the hardware capability. However, why not provide access to double-precision multiply and add-with-carry (subtract with borrow? shift-left?) in the same fashion? twofer x = mul(a,b); would cause x.hi and x.lo to be computed. twofer x = addwithcarry(a,b) ditto. It is frustrating and arbitrary that gcc only does this for division and not anything else. It also is just plain stupid! -- because the C language already provided % and / operators, and gcc's optimizer could presumably recognize whenever anybody was computing both a%b and a/b, and then combine them when generating code. Hence the div(a,b) really was not even necessary for gcc to provide at all, if it had a good enough optimizer+recognizer. But mul(a,b) and add_with_carry really ARE necessary because they are NOT available in C language already and CANNOT be recognized/optimized -- at least not without a rather ridiculous level of cleverness to recognize it whenever I implement double-length multiply in some slow ugly manner as a workaround to overcome this stupidity (there are many possible ways to implement it, so not much hope gcc could recognize them all). -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Need help with PR71976 combine.c::get_last_value returns a wrong result
On 26.07.2016 14:51, Segher Boessenkool wrote:
On Tue, Jul 26, 2016 at 02:14:49PM +0200, Georg-Johann Lay wrote:
which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx.
Total outcome is that the right shift of reg:DI 18 is transformed to a
no-op move and cancelled out in the remainder.
Why does num_sign_bit_copies return something bigger than 8?
Because it thinks the last value was const0_rtx (which is incorrect) and
Why is that incorrect? See insn 43. Is there another insn I missed?
Yes, the insn stream that matters is (prior to combine):
(insn 43 31 44 2 (set (reg:QI 18 r18)
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 44 43 45 2 (set (reg:QI 19 r19 [+1 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 45 44 46 2 (set (reg:QI 20 r20 [+2 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 46 45 47 2 (set (reg:QI 21 r21 [+3 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 47 46 48 2 (set (reg:QI 22 r22 [+4 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 48 47 49 2 (set (reg:QI 23 r23 [+5 ])
(reg:QI 65 [ _3+5 ])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 49 48 50 2 (set (reg:QI 24 r24 [+6 ])
(reg:QI 66 [ _3+6 ])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 50 49 51 2 (set (reg:QI 25 r25 [+7 ])
(reg:QI 67 [ _3+7 ])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 51 50 52 2 (set (reg:QI 16 r16)
(const_int 40 [0x28])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 52 51 61 2 (set (reg:DI 18 r18)
(ashiftrt:DI (reg:DI 18 r18)
(reg:QI 16 r16))) bug-combin.c:29 1417 {ashrdi3_insn}
(expr_list:REG_DEAD (reg:QI 16 r16)
(nil)))
The SETs of insns 43...50 all overlap reg:DI 18. This is what expand does at
it breaks up a DImode move into 8 QImode moves. The first 8 instructions
comprise an &= 0xff00.
It's corect that QI:18 is set to 0, but this does not apply to DI:18 of course.
The problem might be that get_last_value() is called for reg:DI 18 and
combine's internal bookkeeping is incorrect
struct reg_stat_type {
/* Record last point of death of (hard or pseudo) register n. */
rtx_insn *last_death;
/* Record last point of modification of (hard or pseudo) register n. */
rtx_insn *last_set;
.last_set is the set for reg:QI 18 but later insns also change hard reg:DI
18, for example the set of reg:QI 19. This means that the information in
reg_stat_type does not tell the whole story for hard regs.
One fix could be to get the mode precision of the SET from the last_set
insn and only use the information if that mode is at least as wide as the
mode of the register for which get_last_value is called. reg_stat_type has
.last_set_mode for this purpose (QImode in the test case).
Yes, last_set_mode, and there is last_set_sign_bit_copies too. Are those
correct?
(gdb) p *rsp
$9 = {last_death = 0x0, last_set = 0x7730cc00, last_set_value =
0x773094f0, last_set_table_tick = 2, last_set_label = 2,
last_set_nonzero_bits = 0, last_set_sign_bit_copies = 8 '\b', last_set_mode =
QImode, last_set_invalid = 1 '\001', sign_bit_copies = 0 '\000', nonzero_bits =
0, truncation_label = 2, truncated_to_mode = DImode}
(gdb) p rsp->last_set
$10 = (rtx_insn *) 0x7730cc00
(gdb) pr
(insn 43 31 44 2 (set (reg:QI 18 r18)
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(gdb) p rsp->last_set_value
$11 = (rtx) 0x773094f0
(gdb) pr
(const_int 0 [0])
The .last_set_sign_bit_copies is correct if it is applied to QImode, but the
sign bits of reg:DI 18 are contained in reg:QI 25 set by insn 50.
As already said, rsp[regno] is not used to get the number of sign bit copies
but to conclude that DI:18 is entirely set to 0, and the number of sign bit
copies is then computed for that 0.
We do have a value, and it is for this bb.
But not for the complete hard register; it's only for reg:QI 18 which is
one byte of reg:DI 18,
The rest of the hard register bits are set to unspecified values.
No, insns 44...50 set the rest of reg:DI 18 to specified values. This is what
expand does as is lowers DImode to word_mode (QImode for avr).
FYI, FIRST_PSEUDO_REGISTER is 34.
thus the code should never reach this point in the
first place and return earlier. For example:
Index: combine.c
===
--- combine.c (revision 238701)
+++ combine.c (working copy)
@@ -13206,6 +13206,13 @@ get_last_value (const_rtx x)
&& DF_INSN_LUID (rsp->last_set) >= subst_low_luid)
return 0;
+ /* If the lookup is for a hard register make sure that value contains at
least
+ as many bits as x does. */
+
+ if (regno < FIRST_PSEUDO_REGISTER
+ && GET_MODE_PRECISION (rsp->last_set_mode) < GET_MODE_PRECISION
(GET_MODE (x))
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 26/07/16 14:31, Warren D Smith wrote:
> However, why not provide access to double-precision multiply and
> add-with-carry (subtract with borrow? shift-left?) in the same fashion?
>twofer x = mul(a,b); would cause x.hi and x.lo to be computed.
>twofer x = addwithcarry(a,b) ditto.
unsigned __int128 poo(unsigned long a, unsigned long b) {
return (__int128)a * b;
}
unsigned __int128 bar(unsigned __int128 a, unsigned long b) {
return a + b;
}
Andrew.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 26 July 2016 at 14:31, Warren D Smith wrote: > 1. Gcc with stdint.h already > provides such nice predefined types as uint8_t. > Sizes provided are 8,16,32, and 64. > In some sense uint1_t is available too (stdbool.h) > but at least on my machine stdbool uses 8-bits to store a bool, Because that's the smallest addressable unit. > e.g. an array of 1000 bools takes 8000 bits, > which is asinine and kind of defeats the point. If you want 1000 boolean values then don't use 1000 bool variables, do something like std::bitset or std::vector in C++, i.e. create an array of some integer type and write functions for accessing individual bits. > I suggest adding uint1_t, uint2_t and uint4_t support > to gcc, and packed. You can't have a variable of a single bit, because you can't address it. You can have smaller-than-a-byte variables as bitfields inside structs, but you don't need a typedef for that. > 128 would be nice too. GCC already supports __int128 and __uint128 where possible. > It is obnoxious and arbitrary that only 8,16,32,64 are available, It's obviously not arbitrary, it's dictated by the hardware. > and it is a pain to make programmers continually > have to reinvent the wheel to implement packed nybbles, etc -- > and even when I do so, then my implementation results in ugly > code, different than the nice-looking code for packed bytes. > Why not allow me to write uniform code? Why not catch up > to freaking PASCAL from 40 years ago, which already > provided packed arrays? This ought to be pretty trivial given > that you already did 8,16,32,64 to do 1,2,4 also. Patches welcome. > 2. Gcc already provides a way to produce quotient and remainder > simultaneously, producing a struct with two fields as output: >div_t x = div(a,b); causes x.quot = a/b, x.rem = a%b. > Not a lot of people know gcc provides that, but it does, and that is > good, because > it provides access to the hardware capability. GCC doesn't provide that, the C library does, because it's defined by standard C and has been for decades.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 7/26/16, Jonathan Wakely wrote: > On 26 July 2016 at 14:31, Warren D Smith wrote: >> 1. Gcc with stdint.h already >> provides such nice predefined types as uint8_t. >> Sizes provided are 8,16,32, and 64. >> In some sense uint1_t is available too (stdbool.h) >> but at least on my machine stdbool uses 8-bits to store a bool, > > Because that's the smallest addressable unit. --look, I know there is a pascal front end for gcc, so I know gcc could provide packed bool arrays, because whoever wrote pascal-gcc already did provide it. Also, I know on some machines to access a byte you have to get a word (larger than 8 bits) from memory, do shifts and masks. So clearly you already do that inside gcc. It therefore is trivial for you to do uint4_t also, because it would be that exact same code you already have, just change some numbers. The reason C language originally went with 8,16,32 only, was an embarrassing historical accident because the first C compiler was developed on some obsolete DEC PDP machine from hell. DEC no longer exists, and PDP machines also no longer exist. To make things worse, they originally defined C *WITHOUT* actual unambiguous meanings, for example "int" might be who knows how many bits wide, language would not define that. This horrible nonportability again was done because the original developers of C foolishly acted like that one PDP machine was going to be the only machine ever to handle C, in which case their decisions made perfect sense. However, it is now the year 2016.Many other machines with many other word sizes have been developed. It is simply flat out wrong to say that a byte is the "smallest addressable unit" if we are on a machine with a different word size, for example I know 60-bit and 36-bit wide machines were sold at one point, note not divisible by 8. It is correct for some machines, false for other machines. The point of a high level language like C, as opposed to assembler, it to allow portable code to be safely written without the programmer having to worry about the specific peculiarities of just one machine. You, by saying "because 8 bits is the smallest addressable unit" have just said "I am not interested in that goal, I am only interested in my specific one machine." Mistake. And that mistake was exactly the error made when C was originally created. Later it was recognized by consensus that they had indeed made a design error, and stdint.h was brought to us to correct that error. But it failed to fully correct the error because, at least with gcc's implementation of stdint.h, only 8,16,32, and 64 are provided. The standard however allows other sizes also to be provided, like uint2_t. It is just the gcc did not implement other sizes. Nothing is stopping you. A different poster pointed out gcc has implemented 128, and that is fine, but: (a) not my gcc on my machine! (b) it did it with some horrible syntax, rather than the stdint.h syntax uint128_t, just in order to be nonuniform, just in order to annoy me. Now actually 128 really is harder to do, but 1,2,4 are totally trivial for you to do, in fact were already done by gcc-pascal. >> e.g. an array of 1000 bools takes 8000 bits, >> which is asinine and kind of defeats the point. > > If you want 1000 boolean values then don't use 1000 bool variables, do > something like std::bitset or std::vector in C++, i.e. create an > array of some integer type and write functions for accessing > individual bits. --If I did that, then I would need to program in C++. Gcc, however, is a C compiler, not a C++ compiler. Therefore, your answer is not an answer for anybody using C. Also, yes I can, and sometimes have, written my own functions in C to allow use of packed nybbles. Sure. But that totally misses my point, which is, programers should not have to keep on reinventing that wheel; It should be provided by the language so they do not have to. And even if they do, then they are forced to use different syntax for 4 versus for 8, which makes code much uglier and larger and buggier for no reason. >> I suggest adding uint1_t, uint2_t and uint4_t support >> to gcc, and packed. > > You can't have a variable of a single bit, because you can't address it. --You can have a variable of a single bit, because you can address it. > GCC already supports __int128 and __uint128 where possible. --false. It does not support it on my machine. And it is certainly "possible" to support it on my machine. It may be "inconvenient" but it certainly is possible. And note __int128 is a new syntax different from the stdint.h syntax int128_t. If you are going to provide a feature, why not provide it in the syntax you already chose to adopt, and the world already chose to standardize? >> It is obnoxious and arbitrary that only 8,16,32,64 are available, > > It's obviously not arbitrary, it's dictated by the hardware. --the point of a high level language like C, is to allow programmer not to worry about specific hardware quirk
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On Tue, 26 Jul 2016, Warren D Smith wrote: > (And in the case of uint4_t, it actually would not even BE an > "extension" since as I said, > the standard already allows providing other sizes.) Only sizes which are an integer number of bytes with no padding bits. -- Joseph S. Myers jos...@codesourcery.com
GCC 4.9.4 Release Candidate available from gcc.gnu.org
A release candidate for the last release from the GCC 4.9 branch, GCC 4.9.4, is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.9.4-RC-20160726/ and shortly its mirrors. I have sofar bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well, I'd like to release GCC 4.9.4 in the middle of next week and close the GCC 4.9 branch.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On Tue, 26 Jul 2016, Warren D Smith wrote: > However, why not provide access to double-precision multiply and > add-with-carry (subtract with borrow? shift-left?) in the same fashion? >twofer x = mul(a,b); would cause x.hi and x.lo to be computed. >twofer x = addwithcarry(a,b) ditto. If add-with-carry were provided then it would be appropriate to provide Clang-compatible __builtin_addc* (in addition to any type-generic form provided to allow the functionality to be used with types such unsigned __int128). (I don't see Clang built-ins to be compatible with for double-precision multiply.) -- Joseph S. Myers jos...@codesourcery.com
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 26/07/16 15:37, Warren D Smith wrote: > --the reason I am suggesting this to this forum, is I probably am not capable > of > recoding GCC myself. > Why not learn from your own history, and do that again, with these two > extensions? > (And in the case of uint4_t, it actually would not even BE an > "extension" since as I said, > the standard already allows providing other sizes.) Does your history tell you that sarcasm and abuse works as a way to get people to do what you want? Andrew.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 7/26/16, Joseph Myers wrote: > On Tue, 26 Jul 2016, Warren D Smith wrote: > >> (And in the case of uint4_t, it actually would not even BE an >> "extension" since as I said, >> the standard already allows providing other sizes.) > > Only sizes which are an integer number of bytes with no padding bits. wikipedia: "The C99 standard includes definitions of several new integer types to enhance the portability of programs.[2] The already available basic integer types were deemed insufficient, because their actual sizes are implementation defined and may vary across different systems... All new types are defined in header (cinttypes header in C++) and also are available at header (cstdint header in C++). The types can be grouped into the following categories: * Exact-width integer types which are guaranteed to have the same number N of bits across all implementations. Included only if it is available in the implementation..." This wikipedia page nowhere says it must be an integer number of bytes with no padding. And you will notice they *intentionally* chose to name them int8_t meaning 8 BITs wide, and *not* meaning 8 BYTEs wide, intentionally choosing those names presumably because they wanted to permit sizes not a multiple of 8. And they said "only if available in implementation" which gcc chose to interpret as "we're not going to make other sizes available, hahahaha." But gcc could choose to get ahead of the other compilers, leading not following, by making them available. If you were really ambitious you could provide int7_t etc (w.g. all integer sizes up to 64) but I am not asking for that level of ambition. I am asking merely for the easy sizes 1, 2 and 4 which you plainly have already written the code to do, just change some numbers. You are free to attack the standards bodies as being idiots. But they weren't being idiots in this decision.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 07/26/16 16:55, Warren D Smith wrote: And they said "only if available in implementation" which gcc chose to interpret as "we're not going to make other sizes available, hahahaha." "if available in implementation" probably means "if supported by the underlying hardware". So, if your hardware supports direct access to 1, 2, or 4 bit entities your proposal makes sense. regards, chris
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On Tue, 2016-07-26 at 10:37 -0400, Warren D Smith wrote:
> Also, I know on some machines to access a byte you have to get a word
> (larger than 8 bits)
> from memory, do shifts and masks. So clearly you already do that
> inside gcc.
> It therefore is trivial for you to do uint4_t also, because it would
> be that exact same code you already have, just change some numbers.
You should try to do that yourself once. Get the GCC source code and
just "change some numbers here and there" and see how far it goes...
Build instructions can be found here: https://gcc.gnu.org/install/
What you are suggesting looks like a generic way of "doing bitfields",
essentially making every integer a bitfield and things like int8_t,
int16_t turn into exceptions that happen to align with what the
hardware implements?
So instead of ..
struct bleh
{
int a : 6;
int b : 3;
};
.. we get ...
struct bleh
{
int6_t a;
int3_t b;
};
and then sizeof (bleh) = ???
Surely, the compiler can be taught that kind of stuff, it's just a
question of effort.
Alternatively, you can implement an N-bit drop-in integer type in C++11
yourself with container specializations of std::array and std::vector
to get tightly packed e.g. int7_t (still with some padding bits). This
will allow you to evaluate the usefulness and effectiveness of your
proposed extensions in some real-world applications as a start.
Cheers,
Oleg
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On Tue, 26 Jul 2016, Warren D Smith wrote: > > Only sizes which are an integer number of bytes with no padding bits. > > wikipedia: Wikipedia is not the standard (and, to be clear, C99 before TC3 had various defects in the specification as well, so you should not refer to pre-TC3 versions for understanding requirements). C11 6.2.6.1#2 and #4 require that non-bit-fields have an integer number of bytes and consist of n*CHAR_BIT bits, and 7.20.1.1#1 and #2 require the absence of padding bits in intN_t and uintN_t. -- Joseph S. Myers jos...@codesourcery.com
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
--mind-boggling. So they actually intentionally made the language worse in the C11 TC3 revision versus the C99 standard. Sigh. It's really hard to get compiler and language guys to do anything. I suggest the most stunningly obvious idea, they tell me I am an idiot. Then years and years later, they do what I suggested, forgetting entirely that I suggested it and forgetting that it was an idiotic idea. This has happened to me many times. If I were to suggest undoing my (later adopted) "idiotic" suggestion now, those exact same people would undoubtably again tell me I am an idiot. There is absolutely no good reason why things have to be *legislated* to be an integer number of bytes. They could be single bits. It would be fine. PASCAL already provided it 40 years ago. If you wanted to make a packed array of 63 bools, you could pad it up to 64 to fit it in an integer number of bytes. I'd be ok with that. I'm not ok with gratuitously wasting a factor of 8 in memory and/or forcing programmers to do lots more work and use cruddy syntax, merely because the compiler writers were too lazy to just change a few numbers in their code. They make bad decisions then fossilize them. And it is an absolute outrage that every processor in the universe provides "add with carry" but the C language insists on preventing you from accessing that, while providing a way to access combined divide & remainder instead. It is simply not a justifiable decision. You can lead a horse to water... -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On Tue, 26 Jul 2016, Warren D Smith wrote: > --mind-boggling. > So they actually intentionally made the language worse > in the C11 TC3 revision versus the C99 standard. There is no such thing as C11 TC3. All the relevant requirements about being integer numbers of bytes are present in the original C99 (which I expect is available to purchase from organisations specialising in the sale of obsolete standards), as are the relevant requirements on intN_t and uintN_t; it's just that referring to the original C99 for requirements is a bad idea because of several other issues raised in various C99 DRs and addressed through TC1, TC2 and TC3 (all three of which made changes to the specification). Furthermore, while the subclause with wording about representations of types is new in C99, exactly the same requirement about being integer numbers of bytes can be found in C90; see the definition of "object" (subclause 3.14 in C90). No doubt the principle of objects being addressable and made up of bytes, except for the special case of bit-fields, dates back long before C90. -- Joseph S. Myers jos...@codesourcery.com
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 26/07/16 16:55, Warren D Smith wrote: > On 7/26/16, Joseph Myers wrote: >> On Tue, 26 Jul 2016, Warren D Smith wrote: >> >>> (And in the case of uint4_t, it actually would not even BE an >>> "extension" since as I said, >>> the standard already allows providing other sizes.) >> >> Only sizes which are an integer number of bytes with no padding bits. > > wikipedia: > "The C99 standard includes definitions of several new integer types to > enhance the portability of programs.[2] The already available basic > integer types were deemed insufficient, because their actual sizes are > implementation defined and may vary across different systems... All > new types are defined in header (cinttypes header in C++) > and also are available at header (cstdint header in C++). > The types can be grouped into the following categories: > * Exact-width integer types which are guaranteed to have the same > number N of bits across all implementations. Included only if it is > available in the implementation..." > > This wikipedia page nowhere says it must be an integer number of bytes > with no padding. Wikipedia does not define C - the C standards define C. And yes, all types (including extended integer types) in C must be an integer number of bytes. Padding bits are allowed, however. So there is nothing (except sanity) to stop an implementation with 8-bit chars having a 12-bit integer type that is stored in a 16-bit lump. But the only support C allows for an object of size 12 bits on such a platform would be as a bitfield. > And you will notice they *intentionally* chose to name them int8_t > meaning 8 BITs wide, and *not* meaning 8 BYTEs wide, intentionally > choosing those names presumably because they wanted to permit > sizes not a multiple of 8. No, the names were chosen to use bit sizes because a "bit" is clearly defined as a single binary digit. A "byte" in C terms is not necessarily 8 bits - the unambiguous term for a lump of 8 bits is "octet". C defines a "byte" to be the smallest addressable unit of memory, with the constraint of it being at least 8 bits. On a great many systems, a "byte" is precisely 8 bits (i.e., CHAR_BIT == 8). But on other systems it is different. I have worked on devices with 16-bit "bytes" (not with gcc). On these systems, "uint16_t" is exactly the same size as "uint16_t" on an x86 system, because the number of bits is specified. But "uint8_t" simply does not exist on such systems, because the hardware does not support direct access to such units. > > And they said "only if available in implementation" which gcc chose to > interpret as > "we're not going to make other sizes available, hahahaha." But gcc could > choose > to get ahead of the other compilers, leading not following, by > making them available. If you were really ambitious you could provide int7_t > etc (w.g. all integer sizes up to 64) but I am not asking for that > level of ambition. I am asking merely for the easy sizes 1, 2 and 4 > which you plainly have already written > the code to do, just change some numbers. If this were as easy as you seem to think, and as useful as you seem to think, then gcc would support different int sizes. In fact making any kind of dedicated int1_t, int2_t or int4_t support would be difficult in the compiler, and would still not do what you want - the rules of C insist that you be able to take the address of objects of these types, and addresses of different objects are different. Thus the only legal implementation of "int4_t" would have four bits for the data content and padding bits to make up the rest of the byte (typically 8 bits). > > You are free to attack the standards bodies as being idiots. But they weren't > being idiots in this decision. > I don't believe anyone other than you is attacking anyone, or calling anyone "idiots". The gcc developers are very well aware of the standards, including both the flexibility and freedoms they give. They are also very well aware of the desires of programmers, and the practical limitations of compilers and tools. So while they know the standards allow the possibility of an "int4_t" extended integer type, they know it would not be useful (it would not do what you think it would do), as well as being a significant effort to implement.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 26/07/16 16:37, Warren D Smith wrote: You would get on far better here if you tried a little politeness and respect, rather than anger, accusations and confrontation. The C standards were written by a group of very smart and experienced people, refined over a long time based on real-world issues and feedback. The language has been successful for decades. And the gcc implementation of the language is developed by another group of very smart and experienced people, and has also been refined over decades. So if you say one thing, and the C standards and/or the gcc developers say something else, the chances are extremely high that you are wrong and they are right. If the gcc compiler is missing a feature that you would like, it is not because someone is lazy, incompetent, or trying to be difficult - more often, it is simply that the feature you want is not actually a good idea, or it is not worth the effort to implement for the few cases where it would be used, or it is already possible using a different method. > On 7/26/16, Jonathan Wakely wrote: >> On 26 July 2016 at 14:31, Warren D Smith wrote: >>> 1. Gcc with stdint.h already >>> provides such nice predefined types as uint8_t. >>> Sizes provided are 8,16,32, and 64. >>> In some sense uint1_t is available too (stdbool.h) >>> but at least on my machine stdbool uses 8-bits to store a bool, >> >> Because that's the smallest addressable unit. > > --look, I know there is a pascal front end for gcc, so I know gcc could > provide > packed bool arrays, because whoever wrote pascal-gcc already did provide it. You have made it clear that you don't actually understand C in detail. Apparently you also don't understand Pascal, or the underlying hardware of typical processors. Yes, Pascal may provide packed bool arrays. But you cannot take the address of the individual elements in a packed bool array. And Pascal arrays are not the same as C arrays - they contain more information, and are more akin to C++ container types. A single "bool" object in Pascal takes one byte (a single smallest addressable unit, typically 8 bits). Pascal implementations can provide packed bool arrays as a convenience to the programmer - it is a higher level language than C, and provides a number of such conveniences. But the underlying mechanism for accessing elements of the array involves masks and shifts - it is very different from the simple access for an unpacked array. In C, you write your own functions for this sort of thing (or use a library). In C++, standard containers such as std::bitset and std::vector have optimisations to hide the details. So if you want a programming language that lets you have something that is a bit like an array, but with packed boolean elements, and is used transparently like a normal array - then pick a different language than C. > > Also, I know on some machines to access a byte you have to get a word > (larger than 8 bits) > from memory, do shifts and masks. So clearly you already do that inside gcc. No, on systems that have a basic unit of memory that is bigger than 8 bits, your "byte" is bigger than 8 bits and it is the smallest unit you can access. So a DSP devices with 16-bit minimum addressable units has 16-bit "bytes", 16-bit char, CHAR_BIT == 16, sizeof(uint32_t) == 2, and no way to directly access 8-bit units. You have to use bitfields that are 8-bit wide in a struct, or do the masking and shifting yourself. (As far as I know, gcc does not support any targets that have CHAR_BIT other than 8, but the principle is the same as this is basic standard C stuff.) > It therefore is trivial for you to do uint4_t also, because it would > be that exact same code you already have, just change some numbers. No. > > The reason C language originally went with 8,16,32 only, > was an embarrassing historical accident because the first C compiler > was developed on some obsolete DEC PDP machine from hell. 8-bit basic units were already becoming mainstream when C was developed, and were a popular choice. The DEC machine in question was the PDP-11, and it was not obsolete when C was developed, and it was certainly not a "machine from hell". It was one of the most successful and popular minicomputers ever made. (The rumour is that some of the terseness in the C syntax is due to the DEC keyboards being terrible - whatever truth there may be in that, the cpu itself was lovely.) > DEC no longer exists, and PDP machines also no longer exist. > To make things worse, they originally defined C *WITHOUT* > actual unambiguous meanings, for example "int" might be who knows how > many bits wide, language would not define that. This was an active decision to allow greater flexibility of the language, and to make it easier to have implementations of C on systems that could not support sizes such as 8 bit. It means there are C implementations for almost all cpus. It does mean that portable code does not know the exact size of the types on it
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> On Jul 26, 2016, at 12:50 PM, Warren D Smith wrote: > > ... > Sigh. It's really hard to get compiler and language guys to do anything. I find it puzzling that you appear to think that insulting your audience is the best way to influence them. > ... > There is absolutely no good reason why things have to be *legislated* > to be an integer number of bytes. They could be single bits. It > would be fine. PASCAL already provided > it 40 years ago. So what? Pascal is a different language with different goals. The reason there are hundreds of programming languages in the world -- and dozens in current use -- is that each design is a tradeoff of conflicting goals, and each is a different set of choices made for a particular set of reasons. Pascal, Cobol, Lisp, C, and Python all make very different choices. They are all good choices in some situations, and bad choices in another; this is why you sometimes write in C and sometimes in Python. Support for data in sizes different from those native to most modern machine architectures comes at a very substantial cost, in compiler complexity, code size, and execution time. It's clearly doable, and a few languages have done so. But omitting it is a more common tradeoff, and clearly a good choice given the way those languages are received in the marketplace. > If you wanted to make a packed array of 63 bools, > you could pad it up to 64 to fit it in an integer number of bytes. > I'd be ok with that. I'm not ok with gratuitously wasting a factor of > 8 in memory and/or forcing programmers to do lots more work and use > cruddy syntax, merely because the compiler writers were too lazy to > just change a few numbers in their code. Since you clearly don't know much about how compilers work, it would be better to study the subject before expressing an opinion. You might also study the art of communicating persuasively. > And it is an absolute outrage that every processor in the universe > provides "add with carry" but the C language insists on preventing you > from accessing that, while providing a way > to access combined divide & remainder instead. It is simply not a > justifiable decision. You might also study processor architecture some more. If by "every processor" you mean every x86 processor, you might be correct. But of the 15 or so processor architectures I've looked at, I think that only a modest minority have add-carry or add-with-carry instructions. For example, MIPS, which is a very popular architecture in current wide use, does not have such operations. Quite apart from that, it is not the goal of most (if any) high level languages to provide direct access to all CPU facilities. Instead, the more common goal is to provide a clean set of abstractions complete enough to let people write reliable programs for the problem area in question, with minimal effort. So it is with C (and Pascal, for that matter, which doesn't have an add-with-carry primitive either). For those who want to see all the bells and whistles, there's a simple answer: assembly language. paul
Two suggestions for gcc C compiler to extend C language (by WD Smith)
To the guy who falsely claimed MIPS fails to provide an add with carry instruction, a google search in 1 minute finds this: stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly I defy you to find any processor not providing add with carry, (And I'm not talking about semantic bullshit. MIPS provides add with carry, even if they do not call it that, as this answer shows.) Now it might be I'm wrong and some computers now not providing it. If so, that is world damage caused by GCC. How so? Simple. Code out there is written on C. Processor designers observe real world code. "Aha!" They say. "Real word code hardly ever seems to use add-with-carry! I guess we should eliminate it!" If and when that happens it is a disaster, and the direct cause of that disaster, was the laziness of writers of such things as GCC. They cripple the programmer, then the hardware guys say "aha! programmers are crippled! That proves they like being crippled!" OK? So it is not merely that you are providing a bad product, it is worse (if you are right about this) -- actually damaging the world. Now as my critic said (it is amazing the absurd lengths people will go to to pretend fossilized crud was a "good decision") a purpose of languages like C is to provide a nice set of portable abstractions. Well, add with carry IS a nice portable abstraction. So is multiply Nwide*Nwide --> 2Nwide. And as some other critic said, languages have different purposes, and PASCAL may have had different purposes than C. As usual for my critics, again this was confused, because it was an explicit goal of C to get close to the machine. That was not so much a goal of PASCAL. It was a goal of C. That means it is absurd for C to refuse to provide packed boolean arrays while PASCAL does, and also while C already has made uintN_t types for various N. Also, I believe the original machine was a PDP-9 not PDP-11, not that it matters. Look, I could go on. But this is getting silly. Basically, what happens is 1. compiler/language guys do a bad job. 2. others point it out. 3. CLGs then pretend it was a good decision made by very very wise minds for mysterious unknown reasons nobody can explain, or just make shit up, or complain anybody pointing it out is rude, or mumble about different goals of different languages, or invent ludicrous arguments to "justify" situation, or argue anybody could implement it themselves because language is Turing complete, so no need. 4. The real reason they are doing (3) is simple: they are lazy. 5. Pointing our their laziness and incompetence is "rude." But due to the always-response of type 3 made by the CLGs to any suggestion whatever, there is no other alternative, is there? You are forcing it upon me, aren't you? 6. Years and years later eventually the CLGs do the right thing, always pretending it was their own idea and that they'd never said it was idiotic to do it. I just wish this process could be shortcut. Now look. I'm actually willing to write you code to do the things I suggested, e.g. implement packed nybble arrays in C. It will do it with cruddy syntax, but it'll work and pretty efficiently. I'd also be willing to write some assembler patches to implement, e.g. double-length multiply. These will not be a compiler. They will rather, be the sort of annoying workarounds programmers like me have to do all the time, to get around the fact that the compiler and language try to prevent you from doing them. But the thing is, I'm not willing to write that stuff for you unless you promise to actually add these things to GCC. So, will anybody make that promise? -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> On Jul 26, 2016, at 2:07 PM, Warren D Smith wrote: > > To the guy who falsely claimed MIPS fails to provide an add with carry > instruction, > a google search in 1 minute finds this: > > stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly > > I defy you to find any processor not providing add with carry, > (And I'm not talking about semantic bullshit. MIPS provides add with > carry, even if they do not call it that, as this answer shows.) Nonsense. What that example shows is the standard assembly language coding for doing multi-precision addition in machines that do NOT have an add-with-carry instruction (or, as in the case of MIPS, even the concept of carry). The algorithm is simple: add low order parts, see if the result is unsigned less than one of the operands; if yes, add one to the sum of the high order parts. Incidentally, note that this coding pattern only works for two's complement integers. > ... > But the thing is, I'm not willing to write that stuff for you unless > you promise to actually add these things to GCC. So, will anybody > make that promise? I very much doubt it. You might as well stop trying. paul
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
I am assuming you intended to post this on the mailing list, so I have
restored the addresses.
On 26/07/16 19:55, Warren D Smith wrote:
> To the guy who falsely claimed MIPS fails to provide an add with carry
> instruction,
> a google search in 1 minute finds this:
>
> stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly
>
> I defy you to find any processor not providing add with carry,
> (And I'm not talking about semantic bullshit. MIPS provides add with
> carry, even if they do not call it that, as this answer shows.)
No, what the MIPS example shows is that you do not need an "add with
carry" instruction in order to handle multi-precision arithmetic. MIPS
does not have a carry flag, or any sort of condition code register.
This is not an unreasonable design decision - condition code registers
are often bottlenecks that make pipelining or out-of-order scheduling
significantly harder than necessary. Other RISC architectures without
flag registers include the Alpha and RISC-V. You use a similar sequence
to the one you found for MIPS for doing multi-precision addition here.
You may note that the MIPS sequence here translates directly to the
sequence:
typedef struct {
uint32_t lo;
uint32_t hi;
} pair;
pair addPairs(pair a, pair b) {
pair r;
r.lo = a.lo + b.lo;
r.hi = (r.lo < b.lo);
r.hi += a.hi;
r.hi += b.hi;
return r;
}
I don't have a MIPS target gcc conveniently on hand, but I suspect this
C code would generate pretty much the same sequence of instructions.
And note that the C code here is generic - it is not MIPS specific.
>
> Now it might be I'm wrong and some computers now not providing it. If
> so, that is world
> damage caused by GCC.
gcc is an influential project - but not /that/ influential!
Back in the real world, people who design highly successful processor
architectures do so using good, solid technical reasons for their key
design decisions.
> How so? Simple. Code out there is written on C.
> Processor designers observe real world code. "Aha!" They say. "Real
> word code hardly ever seems to use add-with-carry! I guess we should
> eliminate it!"
Processor designers take their target audience into account. And most
targets use C (either directly, or indirectly via libraries, VMs, etc.)
for a good deal of critical programs. So yes, processor designers
consider "how well does this design fit C?". They don't typically think
of gcc exclusively, but C in general.
> If and when that happens it is a disaster, and the direct cause of
> that disaster, was the
> laziness of writers of such things as GCC. They cripple the
> programmer, then the hardware guys say "aha! programmers are crippled!
> That proves they like being crippled!" OK? So it is not merely that
> you are providing a bad product, it is worse (if you are right about
> this) -- actually damaging the world.
But the example you posted showed that there is no need to have access
to the carry flag in C - there is no need to have a carry flag at all.
And when I compiled that code on x86, gcc used the carry flag in order
to generate optimal code with an add and an adc instruction. It really
is hard to do better.
>
> Now as my critic said (it is amazing the absurd lengths people will go
> to to pretend
> fossilized crud was a "good decision") a purpose of languages like C
> is to provide a nice set of portable abstractions.
I have to wonder - why are you using C at all? And why are you using gcc?
>
> Well, add with carry IS a nice portable abstraction.
> So is multiply Nwide*Nwide --> 2Nwide.
>
> And as some other critic said, languages have different purposes,
> and PASCAL may have had different purposes than C.
> As usual for my critics, again this was confused, because it was an explicit
> goal of C to get close to the machine.
>
> That was not so much a goal of PASCAL. It was a goal of C.
> That means it is absurd for C to refuse to provide packed boolean
> arrays while PASCAL does, and also while C already has made uintN_t
> types for various N.
>
> Also, I believe the original machine was a PDP-9 not PDP-11, not that
> it matters.
>
> Look, I could go on. But this is getting silly.
Your first post was silly, and you have gone downhill since then.
> Basically, what happens is
> 1. compiler/language guys do a bad job.
> 2. others point it out.
> 3. CLGs then pretend it was a good decision made by very very wise
> minds for mysterious unknown reasons nobody can explain, or just make
> shit up, or complain anybody
> pointing it out is rude, or mumble about different goals of different
> languages, or invent ludicrous arguments to "justify" situation, or
> argue anybody could implement it
> themselves because language is Turing complete, so no need.
> 4. The real reason they are doing (3) is simple: they are lazy.
> 5. Pointing our their laziness and incompetence is "rude." But due to the
> always-response of type 3 made by the CLGs to any suggestion whatever,
> th
Re: [gimplefe] hacking pass manager
On 20 July 2016 at 18:28, Richard Biener wrote:
> On Wed, Jul 20, 2016 at 1:46 PM, Prathamesh Kulkarni
> wrote:
>> On 20 July 2016 at 11:34, Richard Biener wrote:
>>> On Tue, Jul 19, 2016 at 10:09 PM, Prasad Ghangal
>>> wrote:
On 19 July 2016 at 11:04, Richard Biener
wrote:
> On July 18, 2016 11:05:58 PM GMT+02:00, David Malcolm
> wrote:
>>On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote:
>>> On 19 July 2016 at 00:25, Richard Biener
>>> wrote:
>>> > On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal <
>>> > prasad.ghan...@gmail.com> wrote:
>>> > > On 15 July 2016 at 16:13, Richard Biener <
>>> > > richard.guent...@gmail.com>
>>> > > wrote:
>>> > > > On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
>>> > > > wrote:
>>> > > > > On 8 July 2016 at 13:13, Richard Biener <
>>> > > > > richard.guent...@gmail.com>
>>> > > wrote:
>>> > > > > > On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal
>>> > > wrote:
>>> > > > > > > On 6 July 2016 at 14:24, Richard Biener
>>> > > wrote:
>>> > > > > > > > On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
>>> > > wrote:
>>> > > > > > > > > On 30 June 2016 at 17:10, Richard Biener
>>> > > wrote:
>>> > > > > > > > > > On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>>> > > > > > > > > > wrote:
>>> > > > > > > > > > > On 29 June 2016 at 22:15, Richard Biener
>>> > > wrote:
>>> > > > > > > > > > > > On June 29, 2016 6:20:29 PM GMT+02:00,
>>> > > > > > > > > > > > Prathamesh Kulkarni
>>> > > wrote:
>>> > > > > > > > > > > > > On 18 June 2016 at 12:02, Prasad Ghangal
>>> > >
>>> > > > > > > > > > > > > wrote:
>>> > > > > > > > > > > > > > Hi,
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > I tried hacking pass manager to execute
>>> > > > > > > > > > > > > > only given passes.
>>> > > For this I
>>> > > > > > > > > > > > > > am adding new member as opt_pass
>>> > > > > > > > > > > > > > *custom_pass_list to the
>>> > > function
>>> > > > > > > > > > > > > > structure to store passes need to execute
>>> > > > > > > > > > > > > > and providing the
>>> > > > > > > > > > > > > > custom_pass_list to execute_pass_list()
>>> > > > > > > > > > > > > > function instead of
>>> > > all
>>> > > > > > > > > > > > > passes
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > for test case like-
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > int a;
>>> > > > > > > > > > > > > > void __GIMPLE (execute ("tree-ccp1", "tree
>>> > > > > > > > > > > > > > -fre1")) foo()
>>> > > > > > > > > > > > > > {
>>> > > > > > > > > > > > > > bb_1:
>>> > > > > > > > > > > > > > a = 1 + a;
>>> > > > > > > > > > > > > > }
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > it will execute only given passes i.e. ccp1
>>> > > > > > > > > > > > > > and fre1 pass
>>> > > on the
>>> > > > > > > > > > > > > function
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > and for test case like -
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > int a;
>>> > > > > > > > > > > > > > void __GIMPLE (startwith ("tree-ccp1"))
>>> > > > > > > > > > > > > > foo()
>>> > > > > > > > > > > > > > {
>>> > > > > > > > > > > > > > bb_1:
>>> > > > > > > > > > > > > > a = 1 + a;
>>> > > > > > > > > > > > > > }
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > it will act as a entry point to the
>>> > > > > > > > > > > > > > pipeline and will
>>> > > execute passes
>>> > > > > > > > > > > > > > starting from given pass.
>>> > > > > > > > > > > > > Bike-shedding:
>>> > > > > > > > > > > > > Would it make sense to have syntax for
>>> > > > > > > > > > > > > defining pass ranges
>>> > > to execute
>>> > > > > > > > > > > > > ?
>>> > > > > > > > > > > > > for instance:
>>> > > > > > > > > > > > > void __GIMPLE(execute (pass_start :
>>> > > > > > > > > > > > > pass_end))
>>> > > > > > > > > > > > > which would execute all the passes within
>>> > > > > > > > > > > > > range [pass_start,
>>> > > pass_end],
>>> > > > > > > > > > > > > which would be convenient if the range is
>>> > > > > > > > > > > > > large.
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > But it would rely on a particular pass
>>> > > > > > > > > > > > pipeline, f.e.
>>> > > pass-start appearing before pass-end.
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > Currently control doesn't work 100% as it only
>>> > > > > > > > > > > > replaces
>>> > > all_optimizations but not lowering passes or early opts, nor IPA
>>> > > opts.
>>> > > > > > > > > > > >
>>> > > > > > > > > > >
>>> > > > > > > > > > > Each pass needs GIMPLE in some specific form. So
>>> > > > > > > > > > > I
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
OK, you just said you've used packed nybble arrays a couple of times. Multiplying you by 100,000 that proves if you put it in GCC, you'd save 200,000 programmer hours, which is equivalent to saving over 2 lives. You just said you've written your own double-length multiply. Same proof. Thank you for proving my point. How many deaths does it take before it is worth putting into GCC? And it isn't like I'm suggesting something hard, or which would be unattractive to users. And thanks for the tip on how to do add-with-carry. That's nice. Now I have to ask, now you've helpfully demonstrated how nice it can be, why not put that niceness inside GCC? I mean, if GCC already is going to provide div(a,b) -- it was not me who asked for that, it was GCC that decided to provide it -- which I could have just got in plain C using q=a/b; r=a%b; and depended on optimizer, zero thought required -- then how can just justify GCC *not* providing addc(a,b) when it is trickier for the programmer, so you are clearly providing something more helpful since was more tricky? Why am I bothering? You prove my point then act as though you proved opposite. Concrete examples? Hell, I suggested stdint.h years and years before it came along, and I was told I was an idiot. I suggested making a lot of library functions be builtins, told I was an idiot, and now lo and behold, years and years later, gcc makes many library functions be builtins. I complained the stdio library was a disaster waiting to happen with buffer overflows, told I was an idiot, and lo and behold, years and years later people keep trying to work around that, with at least two people having written nonstandard replacement libraries to try for safety, and huge billions of dollars estimated to be lost due to this bad design. Concerning suggestions I've made that never were adopted, I would like C to have array-bounds checking available as a compiler option. Also profiling. I'd like elsif. I'd like more sophisticated compile time stuff, like right now they have #if, #elsif, #endif. Ok, why not #for? That way we could unroll loops by "doing the loop at compile time" not runtime. (Need to make a language subset intentionally weakened to not be turing complete, i.e. we want to know for sure the compile always will terminate, but still precompiler language could be a good deal more powerful than now.) I could discuss that. I'd like a compile-time language giving you a fair amount of power, but below turing-power, and acting as though it were sensibly designed in from start with similar syntax (within reason) to the actual runtime language -- not intentionally different syntax for no reason aside from trying to annoy people, and not an obvious crude add-on. I'd like different parts of my program to be optimized for space, or for speed -- I get to say for which parts I want which using pragmas. I'd like addons to support multiple entry points for routines easy, so I can make coroutines and "iterators." (This can be done with present C, but it seems a much bigger pain than it needs to be.) Pointer arithmetic is a well known disaster-waiting-to-happen in C, but of course there are compensating performance benefits... but you could get the best of both worlds with ability to declare "safe" pointers e.g. with bounds checking of them added by compiler and the bounds created when the pointer is. Such safety could be turned off with a compiler option for more speed. Point is, C arrays and pointers are very unsafe for a few reasons, but by adding some compiler options and/or language extensions to allow adding safe versions of that stuff, GCC could make it a lot easier on programmers to get a lot safer with near zero effort. But hey, nearly all those ideas actually require work, meanwhile I think uint4_t is nearly trivial by comparison. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
Ok, I'm not affiliated with gcc, nor a committer, I just happen to work on a port to a local architecture. Your first posts were funny to read, and you ignored the answers, and now it's getting old. Not talking for the gcc community, I suggest that you go away and come back when you have code to implement what you propose. Then we can continue that discussion. regards, chris On 07/26/16 21:06, Warren D Smith wrote: OK, you just said you've used packed nybble arrays a couple of times. Multiplying you by 100,000 that proves if you put it in GCC, you'd save 200,000 programmer hours, which is equivalent to saving over 2 lives. You just said you've written your own double-length multiply. Same proof. Thank you for proving my point. How many deaths does it take before it is worth putting into GCC? And it isn't like I'm suggesting something hard, or which would be unattractive to users. And thanks for the tip on how to do add-with-carry. That's nice. Now I have to ask, now you've helpfully demonstrated how nice it can be, why not put that niceness inside GCC? I mean, if GCC already is going to provide div(a,b) -- it was not me who asked for that, it was GCC that decided to provide it -- which I could have just got in plain C using q=a/b; r=a%b; and depended on optimizer, zero thought required -- then how can just justify GCC *not* providing addc(a,b) when it is trickier for the programmer, so you are clearly providing something more helpful since was more tricky? Why am I bothering? You prove my point then act as though you proved opposite. Concrete examples? Hell, I suggested stdint.h years and years before it came along, and I was told I was an idiot. I suggested making a lot of library functions be builtins, told I was an idiot, and now lo and behold, years and years later, gcc makes many library functions be builtins. I complained the stdio library was a disaster waiting to happen with buffer overflows, told I was an idiot, and lo and behold, years and years later people keep trying to work around that, with at least two people having written nonstandard replacement libraries to try for safety, and huge billions of dollars estimated to be lost due to this bad design. Concerning suggestions I've made that never were adopted, I would like C to have array-bounds checking available as a compiler option. Also profiling. I'd like elsif. I'd like more sophisticated compile time stuff, like right now they have #if, #elsif, #endif. Ok, why not #for? That way we could unroll loops by "doing the loop at compile time" not runtime. (Need to make a language subset intentionally weakened to not be turing complete, i.e. we want to know for sure the compile always will terminate, but still precompiler language could be a good deal more powerful than now.) I could discuss that. I'd like a compile-time language giving you a fair amount of power, but below turing-power, and acting as though it were sensibly designed in from start with similar syntax (within reason) to the actual runtime language -- not intentionally different syntax for no reason aside from trying to annoy people, and not an obvious crude add-on. I'd like different parts of my program to be optimized for space, or for speed -- I get to say for which parts I want which using pragmas. I'd like addons to support multiple entry points for routines easy, so I can make coroutines and "iterators." (This can be done with present C, but it seems a much bigger pain than it needs to be.) Pointer arithmetic is a well known disaster-waiting-to-happen in C, but of course there are compensating performance benefits... but you could get the best of both worlds with ability to declare "safe" pointers e.g. with bounds checking of them added by compiler and the bounds created when the pointer is. Such safety could be turned off with a compiler option for more speed. Point is, C arrays and pointers are very unsafe for a few reasons, but by adding some compiler options and/or language extensions to allow adding safe versions of that stuff, GCC could make it a lot easier on programmers to get a lot safer with near zero effort. But hey, nearly all those ideas actually require work, meanwhile I think uint4_t is nearly trivial by comparison.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> OK, you just said you've used packed nybble arrays a couple of times. > Multiplying you by 100,000 that proves if you put it in GCC, > you'd save 200,000 programmer hours, which is equivalent to saving > over 2 lives. I would suggest that you spend time learning basic principles about language design and better understand the concept that not all languages are meant to be used in the same way and for the same purpose before you make any more postings in this thread. Then you'll understand that the above statement is completely meaningless. You very specifically *do not* want to put every possible feature into every language.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
It *isn't* "putting every possible feature into every language." Did I ever advocate that? It's "putting a feature that you already put there, into the language, just no longer arbitrarily selecting certain integer sizes and excluding others." Am I making syntax more complicated? No. I am if anything suggesting making it simpler by removing arbitrary rules that only complicated situation. Am I making compiler more complicated? No, the code to do this was already written (just with different numbers), and by doing what I say the compiler could actually be simplified in some ways. And no, I do not think "saving a life" worth of time is "completely meaningless." And also, it is actually C's explicit mission to be close to the machine, trying basically to provide a user-friendly portable machine-model. Given that is its design mission, it is rather absurd to disallow access to various common machine primitives like multiply-hi&lo, shift with carry, etc. Adding those would in no way complicate the overall language design, it'd just be another builtin function just like the ones you already have put in. If I told you to remove div(a,b) from GCC because it was a fairly silly complication and unnecessary feature, that'd be true, and yet you would tell me I was an idiot. If I tell you to put in mul(a,b): then it is a less-silly, more-useful, thing, which you just (see previous sentence) agreed with me was worthwhile. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
And hell, GCC already includes a lot of really really obscure builtin functions which are one hell of a lot less common & useful than multiply-hi&lo. I merely cited div(a,b) because it was one of the least obscure among them. How about freaking "isgraph" and "_mm_set1_epi32"? I mean how can you justify building them in, but not this? You cannot. And that isn't because I failed to "learn basic principles about language design." -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> It *isn't* "putting every possible feature into every language." > Did I ever advocate that? Yes. When you say "X is a useful feature, therefore we should put it into language Y", you are indeed implicitly advocating that. Because if that were *not* the case, then saying that X is *useful* says nothing whatever about whether it should be put into Y: there will be dozens, if not hundreds, of useful feature that will not be in Y. > Am I making syntax more complicated? No. I am if anything > suggesting making it simpler by removing arbitrary rules that only > complicated situation. Am I making compiler more complicated? No, > the code to do this was already written (just with different numbers), > and by doing what I say the compiler could actually be simplified > in some ways. You are making the *language* more complicated because you cannot look at each feature in isolation, but rather must look at how they interact with the other features of the language, among other issues. As I said, please study language design concepts before continuing this discussion.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> And hell, GCC already includes a lot of really really obscure > builtin functions which are one hell of a lot less common & useful > than multiply-hi&lo. Which exactly proves the point that people are making: whether something is "common & useful" is rarely the criteria that's used in deciding whether a language should include that thing. > And that isn't because I failed to "learn basic principles about > language design." Sorry, but it precisely is.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
>> But it failed to fully correct the error >> because, at least with gcc's implementation of stdint.h, only 8,16,32, >> and 64 are provided. >These cover the needs of virtually everyone in virtually all cases. --a bold claim, made with zero evidence presented. But since we know that even 40 years ago, PASCAL felt the need to provide packed boolean arrays, we know that 8-64 failed to cover the needs of "virtually everyone in virtually all cases." Looks to me like you just make stuff up. My claim is: if you build it, they will come. People will like the fact that gcc provides a little more than the bare minimum it is allowed to provide. Also, I'm somewhat amazed how it is argued to me that a 9-bit machine the PDP-10 is covered by C fine, but yet, C insists on having everything a multiple of 8 bits with padding bits disallowed, and that too is fine, and both these facts refute me. Oh. I've tried to make my critics argue against themselves by giving examples where their statements contradict decisions they already made to put X into GCC, but those examples just appears to be ignored by you all. Obviously you feel that you yourselves back when you made the decision to add X, were being an idiot. Which is strange, but makes it clear it ultimately is not I who it criticizing you, it is you who are criticizing you. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: [gimplefe] hacking pass manager
On 27 July 2016 at 00:20, Prasad Ghangal wrote:
> On 20 July 2016 at 18:28, Richard Biener wrote:
>> On Wed, Jul 20, 2016 at 1:46 PM, Prathamesh Kulkarni
>> wrote:
>>> On 20 July 2016 at 11:34, Richard Biener wrote:
On Tue, Jul 19, 2016 at 10:09 PM, Prasad Ghangal
wrote:
> On 19 July 2016 at 11:04, Richard Biener
> wrote:
>> On July 18, 2016 11:05:58 PM GMT+02:00, David Malcolm
>> wrote:
>>>On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote:
On 19 July 2016 at 00:25, Richard Biener
wrote:
> On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal <
> prasad.ghan...@gmail.com> wrote:
> > On 15 July 2016 at 16:13, Richard Biener <
> > richard.guent...@gmail.com>
> > wrote:
> > > On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
> > > wrote:
> > > > On 8 July 2016 at 13:13, Richard Biener <
> > > > richard.guent...@gmail.com>
> > wrote:
> > > > > On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal
> > wrote:
> > > > > > On 6 July 2016 at 14:24, Richard Biener
> > wrote:
> > > > > > > On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
> > wrote:
> > > > > > > > On 30 June 2016 at 17:10, Richard Biener
> > wrote:
> > > > > > > > > On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
> > > > > > > > > wrote:
> > > > > > > > > > On 29 June 2016 at 22:15, Richard Biener
> > wrote:
> > > > > > > > > > > On June 29, 2016 6:20:29 PM GMT+02:00,
> > > > > > > > > > > Prathamesh Kulkarni
> > wrote:
> > > > > > > > > > > > On 18 June 2016 at 12:02, Prasad Ghangal
> >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I tried hacking pass manager to execute
> > > > > > > > > > > > > only given passes.
> > For this I
> > > > > > > > > > > > > am adding new member as opt_pass
> > > > > > > > > > > > > *custom_pass_list to the
> > function
> > > > > > > > > > > > > structure to store passes need to execute
> > > > > > > > > > > > > and providing the
> > > > > > > > > > > > > custom_pass_list to execute_pass_list()
> > > > > > > > > > > > > function instead of
> > all
> > > > > > > > > > > > passes
> > > > > > > > > > > > >
> > > > > > > > > > > > > for test case like-
> > > > > > > > > > > > >
> > > > > > > > > > > > > int a;
> > > > > > > > > > > > > void __GIMPLE (execute ("tree-ccp1", "tree
> > > > > > > > > > > > > -fre1")) foo()
> > > > > > > > > > > > > {
> > > > > > > > > > > > > bb_1:
> > > > > > > > > > > > > a = 1 + a;
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > it will execute only given passes i.e. ccp1
> > > > > > > > > > > > > and fre1 pass
> > on the
> > > > > > > > > > > > function
> > > > > > > > > > > > >
> > > > > > > > > > > > > and for test case like -
> > > > > > > > > > > > >
> > > > > > > > > > > > > int a;
> > > > > > > > > > > > > void __GIMPLE (startwith ("tree-ccp1"))
> > > > > > > > > > > > > foo()
> > > > > > > > > > > > > {
> > > > > > > > > > > > > bb_1:
> > > > > > > > > > > > > a = 1 + a;
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > it will act as a entry point to the
> > > > > > > > > > > > > pipeline and will
> > execute passes
> > > > > > > > > > > > > starting from given pass.
> > > > > > > > > > > > Bike-shedding:
> > > > > > > > > > > > Would it make sense to have syntax for
> > > > > > > > > > > > defining pass ranges
> > to execute
> > > > > > > > > > > > ?
> > > > > > > > > > > > for instance:
> > > > > > > > > > > > void __GIMPLE(execute (pass_start :
> > > > > > > > > > > > pass_end))
> > > > > > > > > > > > which would execute all the passes within
> > > > > > > > > > > > range [pass_start,
> > pass_end],
> > > > > > > > > > > > which would be convenient if the range is
> > > > > > > > > > > > large.
> > > > > > > > > > >
> > > > > > > > > > > But it would rely on a particular pass
> > > > > > > > > > > pipeline, f.e.
> > pass-start appearing before pass-end.
> > > > > > > > > > >
> > > > > > > > > > > Currently control doesn't work 100% as it only
> > > > > > > > > > > replaces
> > all_optimizations but not lowering passes or early opts, nor IPA
> > opts.
>>>
gcc-5-20160726 is now available
Snapshot gcc-5-20160726 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160726/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 238772 You'll find: gcc-5-20160726.tar.bz2 Complete GCC MD5=eb41dc6b288564073b7a78052c4dfced SHA1=4db5359793fc47d1b1a9470228f5b94fa61f5939 Diffs from 5-20160719 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
