Re: [gimplefe] hacking pass manager
Thanks,
Prasad
On 29 July 2016 at 06:56, Prathamesh Kulkarni
wrote:
> On 29 July 2016 at 00:01, Prasad Ghangal wrote:
>> On 27 July 2016 at 14:22, Richard Biener wrote:
>>> On Tue, Jul 26, 2016 at 11:38 PM, Prathamesh Kulkarni
>>> wrote:
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 :
> > > > > > > > > > >
Re: [gimplefe] hacking pass manager
On Fri, Jul 29, 2016 at 9:03 AM, Prasad Ghangal
wrote:
> Thanks,
> Prasad
>
>
> On 29 July 2016 at 06:56, Prathamesh Kulkarni
> wrote:
>> On 29 July 2016 at 00:01, Prasad Ghangal wrote:
>>> On 27 July 2016 at 14:22, Richard Biener wrote:
On Tue, Jul 26, 2016 at 11:38 PM, Prathamesh Kulkarni
wrote:
> On 27 July 2016 at 00:20, Prasad Ghangal wrote:
There is one other feature missing for SSA name parsing (forget to mention
that)
which is parsing of default def SSA names. Those are for example used for
parameters and currently dumped like
foo (int i)
{
int D.1759;
int _2;
:
_2 = i_1(D) + 1;
return _2;
}
for int foo (int i) { return i + 1; }. Here 'i_1(D)' is the
default-def of 'i' which
in case of a parameter is the value at function start and in case of a
non-parameter
is simply "undefined". '(D)' is again somewhat awkward to parse but I
guess we
can cope with that ;) A default-def needs to be registered like
arg = make_ssa_name_fn (cfun, lookup_name (id), ...);
set_ssa_default_def (cfun, lookup_name (id), arg);
"undefined" SSA names appear often in PHIs (and of course for parameters).
>>>
>>> This updated patch tries to parse default def ssa names
>> Um does this emit error for cases like a_1() and a_(D) ?
>> From the code it appears to me that parsing 'D' is made optional, so
>> id_version() would be accepted.
>> Perhaps have an else for the if (!strcmp("D", ...) that emits parse error ?
>>
> Right. Currently it gives ICE but we can handle it with better way.
>
>> Btw for the following case:
>> int a;
>> int a_1;
>> int x = a_1 + 1;
>> What does a_1 refer to in "int x = a_1 + 1" ? the ssa-version of 'a'
>> or the variable 'a_1' ?
>> I think from the code it would refer to ssa-version of a ? However the
>> reference looks
>> ambiguous to me (since we also allow variables in non-ssa form).
>>
> we are guarding it with condition
> if (TREE_CODE (c_parser_peek_token (parser)->value) == IDENTIFIER_NODE
> && !lookup_name (c_parser_peek_token (parser)->value))
> so that shouldn't happen.
Note that the example is indeed ambiguous. As said previously rejecting all
invalid source shouldn't be necessarily scope of the GSoC project. In this
particular case the issue is from using _ as the separator for the SSA name
version - the source simply has to cope with that (or we need to choose sth
else). Similar issue is that a_1(D) can also parse as a function call in C.
Btw, I'd like to see some testcases for the SSA name parsing in the testsuite.
Thanks,
Richard.
>
> Thanks,
> Prasad
>
>> Thanks,
>> Prathamesh
>>>
>>> Thanks,
>>> Prasad
>>>
Thanks,
Richard.
> Thanks,
> Prathamesh
>>
>> for testcase :
>>
>> void __GIMPLE () foo()
>> {
>> int a;
>> bb_2:
>> if (a > 4)
>> goto bb_3;
>> else
>> goto bb_4;
>> bb_3:
>> a_1 = 55;
>> goto bb_5;
>>
>> bb_4:
>> a_2 = 99;
>>
>> bb_5:
>> a_3 = __PHI (bb_3: a_1, bb_4: a_2);
>> a_4 = a_3 + 3;
>> return;
>> }
>>
>> I am getting ssa dump as:
>>
>> /* Function foo (foo, funcdef_no=0, decl_uid=1744, cgraph_uid=0,
>> symbol_order=0)*/
>>
>> void
>> foo ()
>> {
>> bb_2:
>> if (a_5 > 4)
>> goto bb_3;
>> else
>> goto bb_4;
>>
>> bb_3:
>> a_1 = 55;
>> goto bb_5;
>>
>> bb_4:
>> a_2 = 99;
>>
>> a_3 = __PHI (bb_3: a_1, bb_4: a_2)
>> bb_5:
>> a_4 = a_3 + 3;
>> return;
>>
>> }
>>
>>> Richard.
>>>
Thanks,
Prathamesh
>
> Richard.
>
>>
>>> Richard.
>>>
Dave
>>>
>>>
Re: Need help with PR71976 combine.c::get_last_value returns a wrong result
Hi Johann, I tested a variant of your patch, building Linux for 32 different (sub-)architectures; surprisingly (to me) there are no regressions at all. Do you want to send it to gcc-patches? Segher diff --git a/gcc/combine.c b/gcc/combine.c index 77e0d2b..750bf83 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -13240,6 +13240,12 @@ get_last_value (const_rtx x) && DF_INSN_LUID (rsp->last_set) >= subst_low_luid) return 0; + /* If fewer bits were set than what we are asked for now, we cannot use + the value. */ + if (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; -- 1.9.3
Question about Cortex bit-banding feature
Some processor architectures do support bitwise access to memory, eg. ARM
Cortex-M and 8051 (by ARM called bit-banding).
In these architectures a single bit can somewhat be addressable, but only as an
'aliased' memory region for another memory address.
I noticed that Keil ARMCC compiler now seems to support this huge optimization
possibility.
ARMCC mark bit-bandable types as __attribute__((bitband)), then when declaring,
an reference to bit-banded memory is given.
typedef struct
{
char i : 1;
int j : 2;
int k : 3;
} BB __attribute__((bitband));
BB bb __attribute__((at(0x2004)));
void foo(void)
{
bb.i = 1;
}
Should something similar be possible in GCC, using attributes or similar to
mark this feature possible to utilize,
then pick up this at a very late target specific optimization pass that could
use bit-banding when possible?
Like eg. a Cortex peephole2 or something similar?
Have anyone maybe already tried to look into this feature in GCC?
Is it a good idea, or even possible?
Refs:
http://www.keil.com/support/man/docs/armcc/armcc_chr1359124979689.htm
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/15921.html
https://answers.launchpad.net/gcc-arm-embedded/+question/228758
Best Regards,
Fredrik
Re: Need help with PR71976 combine.c::get_last_value returns a wrong result
On 29.07.2016 09:47, Segher Boessenkool wrote: Hi Johann, I tested a variant of your patch, building Linux for 32 different (sub-)architectures; surprisingly (to me) there are no regressions at all. I am not so surprised because most backends don't make such an intense use of hard-regs like the avr BE does. Do you want to send it to gcc-patches? https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01921.html There might still problems linger around if hard-regs are used: Suppose we set the reg in DImode and then get_last_value is called for the same reg in SImode. Using the DI value might be wrong, e.g. if it is used to compute the sign (on little endian) or the number of sign bit copies. Anyway, for now I am happy with the current solution. Many thanks for your patient help. Johann Segher diff --git a/gcc/combine.c b/gcc/combine.c index 77e0d2b..750bf83 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -13240,6 +13240,12 @@ get_last_value (const_rtx x) && DF_INSN_LUID (rsp->last_set) >= subst_low_luid) return 0; + /* If fewer bits were set than what we are asked for now, we cannot use + the value. */ + if (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;
Re: [gimplefe] hacking pass manager
Thanks,
Prasad
On 29 July 2016 at 12:55, Richard Biener wrote:
> On Fri, Jul 29, 2016 at 9:03 AM, Prasad Ghangal
> wrote:
>> Thanks,
>> Prasad
>>
>>
>> On 29 July 2016 at 06:56, Prathamesh Kulkarni
>> wrote:
>>> On 29 July 2016 at 00:01, Prasad Ghangal wrote:
On 27 July 2016 at 14:22, Richard Biener
wrote:
> On Tue, Jul 26, 2016 at 11:38 PM, Prathamesh Kulkarni
> wrote:
>> On 27 July 2016 at 00:20, Prasad Ghangal
>> wrote:
> There is one other feature missing for SSA name parsing (forget to
> mention that)
> which is parsing of default def SSA names. Those are for example used for
> parameters and currently dumped like
>
> foo (int i)
> {
> int D.1759;
> int _2;
>
> :
> _2 = i_1(D) + 1;
> return _2;
> }
>
> for int foo (int i) { return i + 1; }. Here 'i_1(D)' is the
> default-def of 'i' which
> in case of a parameter is the value at function start and in case of a
> non-parameter
> is simply "undefined". '(D)' is again somewhat awkward to parse but I
> guess we
> can cope with that ;) A default-def needs to be registered like
>
> arg = make_ssa_name_fn (cfun, lookup_name (id), ...);
> set_ssa_default_def (cfun, lookup_name (id), arg);
>
> "undefined" SSA names appear often in PHIs (and of course for parameters).
>
This updated patch tries to parse default def ssa names
>>> Um does this emit error for cases like a_1() and a_(D) ?
>>> From the code it appears to me that parsing 'D' is made optional, so
>>> id_version() would be accepted.
>>> Perhaps have an else for the if (!strcmp("D", ...) that emits parse error ?
>>>
>> Right. Currently it gives ICE but we can handle it with better way.
>>
>>> Btw for the following case:
>>> int a;
>>> int a_1;
>>> int x = a_1 + 1;
>>> What does a_1 refer to in "int x = a_1 + 1" ? the ssa-version of 'a'
>>> or the variable 'a_1' ?
>>> I think from the code it would refer to ssa-version of a ? However the
>>> reference looks
>>> ambiguous to me (since we also allow variables in non-ssa form).
>>>
>> we are guarding it with condition
>> if (TREE_CODE (c_parser_peek_token (parser)->value) == IDENTIFIER_NODE
>> && !lookup_name (c_parser_peek_token (parser)->value))
>> so that shouldn't happen.
>
> Note that the example is indeed ambiguous. As said previously rejecting all
> invalid source shouldn't be necessarily scope of the GSoC project. In this
> particular case the issue is from using _ as the separator for the SSA name
> version - the source simply has to cope with that (or we need to choose sth
> else). Similar issue is that a_1(D) can also parse as a function call in C.
>
> Btw, I'd like to see some testcases for the SSA name parsing in the testsuite.
>
I have added testcases for __PHI and ssa names
Thanks,
Prasad
> Thanks,
> Richard.
>
>>
>> Thanks,
>> Prasad
>>
>>> Thanks,
>>> Prathamesh
Thanks,
Prasad
> Thanks,
> Richard.
>
>> Thanks,
>> Prathamesh
>>>
>>> for testcase :
>>>
>>> void __GIMPLE () foo()
>>> {
>>> int a;
>>> bb_2:
>>> if (a > 4)
>>> goto bb_3;
>>> else
>>> goto bb_4;
>>> bb_3:
>>> a_1 = 55;
>>> goto bb_5;
>>>
>>> bb_4:
>>> a_2 = 99;
>>>
>>> bb_5:
>>> a_3 = __PHI (bb_3: a_1, bb_4: a_2);
>>> a_4 = a_3 + 3;
>>> return;
>>> }
>>>
>>> I am getting ssa dump as:
>>>
>>> /* Function foo (foo, funcdef_no=0, decl_uid=1744, cgraph_uid=0,
>>> symbol_order=0)*/
>>>
>>> void
>>> foo ()
>>> {
>>> bb_2:
>>> if (a_5 > 4)
>>> goto bb_3;
>>> else
>>> goto bb_4;
>>>
>>> bb_3:
>>> a_1 = 55;
>>> goto bb_5;
>>>
>>> bb_4:
>>> a_2 = 99;
>>>
>>> a_3 = __PHI (bb_3: a_1, bb_4: a_2)
>>> bb_5:
>>> a_4 = a_3 + 3;
>>> return;
>>>
>>> }
>>>
Richard.
> Thanks,
> Prathamesh
>>
>> Richard.
>>
>>>
Richard.
>Dave
Re: Question about Cortex bit-banding feature
On 29/07/16 10:25, Fredrik Hederstierna wrote:
> Some processor architectures do support bitwise access to memory, eg. ARM
> Cortex-M and 8051 (by ARM called bit-banding).
> In these architectures a single bit can somewhat be addressable, but only as
> an 'aliased' memory region for another memory address.
>
> I noticed that Keil ARMCC compiler now seems to support this huge
> optimization possibility.
> ARMCC mark bit-bandable types as __attribute__((bitband)), then when
> declaring, an reference to bit-banded memory is given.
>
> typedef struct
> {
> char i : 1;
> int j : 2;
> int k : 3;
> } BB __attribute__((bitband));
>
> BB bb __attribute__((at(0x2004)));
>
> void foo(void)
> {
> bb.i = 1;
> }
>
> Should something similar be possible in GCC, using attributes or similar to
> mark this feature possible to utilize,
> then pick up this at a very late target specific optimization pass that could
> use bit-banding when possible?
> Like eg. a Cortex peephole2 or something similar?
>
> Have anyone maybe already tried to look into this feature in GCC?
> Is it a good idea, or even possible?
>
> Refs:
> http://www.keil.com/support/man/docs/armcc/armcc_chr1359124979689.htm
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/15921.html
> https://answers.launchpad.net/gcc-arm-embedded/+question/228758
>
> Best Regards,
> Fredrik
>
The third link here gives you some indication of the issues involved.
In general, I think it would be a substantial effort for the compiler to
handle the idea that the same object can be changed in different ways at
different addresses. In particular, when changing bitfields the
compiler will read in the old struct, modify it, then write it out
again. If it needs to make another change, it will skip the read - and
may skip the first write too. If some of its modifications are done
using bitband writes, it is going to get out of sync pretty quickly.
Re: Need help with PR71976 combine.c::get_last_value returns a wrong result
On Fri, Jul 29, 2016 at 11:05:13AM +0200, Georg-Johann Lay wrote: > There might still problems linger around if hard-regs are used: > > Suppose we set the reg in DImode and then get_last_value is called for the > same reg in SImode. Using the DI value might be wrong, e.g. if it is used > to compute the sign (on little endian) or the number of sign bit copies. rtlanal.c:num_sign_bit_copies1, see the part after /* For a smaller object, just ignore the high bits. */ Cheers, Segher
Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?
On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote:
On 25/07/16 21:16, Joseph Myers wrote:
On Mon, 25 Jul 2016, Jeff Law wrote:
I'll pre-approve removing those bits. Alternately, you could look to
resync
with glibc, though that could prove painful after 15 years of
divergence.
The current glibc implementation is completely different; the libiberty
version was replaced in glibc many years ago. Obsolete libiberty by
gnulib for all its users and you get a portable version of the current
glibc regex that way
BTW, this is what Ayush is trying to do:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html
https://gcc.gnu.org/wiki/replacelibibertywithgnulib
It would be great if someone could review his patches. I cannot approve
them myself.
You could even ask him to look next at replacing the libiberty version
of regex.c with gnulib's in GCC. It is on his TODO list.
Well, if libiberty is going to be replaced en masse by gnulib, then
there's no sense in me cleaning up libiberty's regex.
Out of curiosity I tested gnulib's regex implementation by building
glibc (since it seems to be the same code) with my -Walloca patch
(-Walloca-larger-than=4096). Cursory tests show that libc's regex*.c
are in much better shape with regards to unbounded allocas. Actually, I
only see one real problem and one possible false positive.
For the curious, the possible unbounded alloca is in gnulib's regcomp.c:
if ((bufp->syntax & RE_ICASE) && dfa->mb_cur_max > 1)
{
unsigned char *buf = alloca (dfa->mb_cur_max), *p;
Before I spend any more time on this, is there a plan to review Ayush's
work for say GCC 7? I obviously only care about regex* right now, or
any alloca users in libiberty :).
Aldy
Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?
On 07/29/2016 07:30 AM, Aldy Hernandez wrote: On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote: On 25/07/16 21:16, Joseph Myers wrote: On Mon, 25 Jul 2016, Jeff Law wrote: I'll pre-approve removing those bits. Alternately, you could look to resync with glibc, though that could prove painful after 15 years of divergence. The current glibc implementation is completely different; the libiberty version was replaced in glibc many years ago. Obsolete libiberty by gnulib for all its users and you get a portable version of the current glibc regex that way BTW, this is what Ayush is trying to do: https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html https://gcc.gnu.org/wiki/replacelibibertywithgnulib It would be great if someone could review his patches. I cannot approve them myself. You could even ask him to look next at replacing the libiberty version of regex.c with gnulib's in GCC. It is on his TODO list. Well, if libiberty is going to be replaced en masse by gnulib, then there's no sense in me cleaning up libiberty's regex. BTW, does this libiberty replacement project also fix binutils and gdb, or will these other libiberty users require independent patches for their respective projects? Aldy
Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?
On Fri, 29 Jul 2016, Aldy Hernandez wrote: > BTW, does this libiberty replacement project also fix binutils and gdb, or > will these other libiberty users require independent patches for their > respective projects? GDB is already making extensive use of gnulib (I don't know to what extent it still depends on anything from libiberty). I think it would make sense for binutils to do so as well - on the general principle that the GNU project as a whole only needs one such portability / utility library and it's best for the efforts on such a library to go in one place so they benefit as many GNU programs as possible - but that's not part of this project. -- Joseph S. Myers jos...@codesourcery.com
Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?
On 07/29/2016 05:30 AM, Aldy Hernandez wrote:
On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote:
On 25/07/16 21:16, Joseph Myers wrote:
On Mon, 25 Jul 2016, Jeff Law wrote:
I'll pre-approve removing those bits. Alternately, you could look to
resync
with glibc, though that could prove painful after 15 years of
divergence.
The current glibc implementation is completely different; the libiberty
version was replaced in glibc many years ago. Obsolete libiberty by
gnulib for all its users and you get a portable version of the current
glibc regex that way
BTW, this is what Ayush is trying to do:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html
https://gcc.gnu.org/wiki/replacelibibertywithgnulib
It would be great if someone could review his patches. I cannot approve
them myself.
You could even ask him to look next at replacing the libiberty version
of regex.c with gnulib's in GCC. It is on his TODO list.
Well, if libiberty is going to be replaced en masse by gnulib, then
there's no sense in me cleaning up libiberty's regex.
Out of curiosity I tested gnulib's regex implementation by building
glibc (since it seems to be the same code) with my -Walloca patch
(-Walloca-larger-than=4096). Cursory tests show that libc's regex*.c
are in much better shape with regards to unbounded allocas. Actually, I
only see one real problem and one possible false positive.
For the curious, the possible unbounded alloca is in gnulib's regcomp.c:
if ((bufp->syntax & RE_ICASE) && dfa->mb_cur_max > 1)
{
unsigned char *buf = alloca (dfa->mb_cur_max), *p;
Before I spend any more time on this, is there a plan to review Ayush's
work for say GCC 7? I obviously only care about regex* right now, or
any alloca users in libiberty :).
I'm not sure who's taking the lead on reviewing Ayush's work. But I do
expect someone will own it at some point in advance of stage1 close.
jeff
Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?
On 07/29/2016 05:34 AM, Aldy Hernandez wrote: On 07/29/2016 07:30 AM, Aldy Hernandez wrote: On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote: On 25/07/16 21:16, Joseph Myers wrote: On Mon, 25 Jul 2016, Jeff Law wrote: I'll pre-approve removing those bits. Alternately, you could look to resync with glibc, though that could prove painful after 15 years of divergence. The current glibc implementation is completely different; the libiberty version was replaced in glibc many years ago. Obsolete libiberty by gnulib for all its users and you get a portable version of the current glibc regex that way BTW, this is what Ayush is trying to do: https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html https://gcc.gnu.org/wiki/replacelibibertywithgnulib It would be great if someone could review his patches. I cannot approve them myself. You could even ask him to look next at replacing the libiberty version of regex.c with gnulib's in GCC. It is on his TODO list. Well, if libiberty is going to be replaced en masse by gnulib, then there's no sense in me cleaning up libiberty's regex. BTW, does this libiberty replacement project also fix binutils and gdb, or will these other libiberty users require independent patches for their respective projects? I think other users of libibery own the decision whether or not to switch from libiberty to gnulib and if they decide to switch they also own the mechanics of making the change. Jeff
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> Booleans are very useful - they turn up all over the place in programming. > > Nibbles, on the other hand, are almost totally useless. There are very, > very few situations where you need to store a number that is within the > range 0 .. 15, and are so tightly constrained for space that you can't > use an 8-bit byte (or whatever size of byte your target uses). --Why does any programmer want to have a large good-quality-code-producing C compiler like gcc, as opposed to the crudest possible (but working) translator? It is for performance. If they did not care about performance, and only cared about correctness, they would not want gcc, they'd want the simpler smaller compiler, since more likely to be correct. Now why do programmers care about performance? Two reasons: memory space, and time. If programs are not going to come anywhere near memory capacity or time-capacity, then nobody needs gcc, and I have to wonder why you work on it at all. OK? So the sole rationale for the existence of large good-quality-code-producing C compilers like gcc, is for space and/or time performance. Now, suppose you are a memory-performance programmer. In that case, you are pushing memory capacity limits. Therefore, you often want to use the smallest available size for each information-packet in your program, and you want them packed. It happens that power-2 sizes (1,2,4,8,16,... bits) are more convenient, fairly small in number, and assure optimality to within a factor of 2. So as a first step, I would recommend any compiler that aims to satisfy space-performance programmers, should provide power-2 sizes, with packing. (A more ambitious step would be all sizes, power-2 or not.) Now suppose you are a time-performance programmer. In that case, you also care about memory because of the cache. I have done tests on my computer indicating that random memory accesses cost a factor about 70 more time, if array is too large. That means space performance is time performance. OK? Now it is arrogant and obnoxious for somebody to tell me certain info-packet sizes (like 4) are useless while others (like 1 and 32) are useful, just since they feel that way, and the main reason they feel that way is they designed gcc to make it hard for anybody to use size 4, thus causing fewer people to use size 4, thus causing mis-assessment 4 is less useful. The truth is, all sizes are useful, and power2 sizes provide access to all sizes (to within a factor 2). But anyhow since you have just agreed size 1 (bools) are useful, I suggest ability to pack them is useful. E.g. sieve of Eratosthenes, algorithm developed over 2000 years ago and in a large fraction of all programming textbooks, wants huge arrays of packed bools. It is possible all those authors were idiots, and then I suggest you write letters to them saying so. SUMMARY: Every programmer for which gcc matters (as opposed to simplest C compiler) wants space performance. That is provided by packing and by power-2 datachunk sizes. "Every" = Large enough demand for you? > A boolean is a flag, and is a common basic type of data - just like a > character, or an integer. A nibble is a particular constrained size of > integer that fits badly with most hardware, is unsupported by almost any > programming language, and has little real-world use. --nybbles fit excellently with all hardware I've ever used. C already supports "enum" types, which in a large fraction of practical uses, are nybbles. Either these are packed nybbles, or not. If are, then you've already done the coding for it. If not, providing enums in this way was inappropriate for performance language. > On the very rare > occasion where you want to use 4 bits but can't use 8, you can use a > bitfield in C - or write appropriate access functions with shifts and > masks. --Then your code will be nonuniform treatment for 4 vs 8, and will be larger and buggier, for no reason. 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. >>> >>> That claim is absurd in every way imaginable. >> >> --I was unaware that "multiplication" was absurd. > > No, what is absurd is that you think that having a "mul" builtin would > save me time, and that you can pick a number out of the air to guess how > many people this applies to, and that you can get a total "programmer > hours saved" result. And what is even more absurd is that you claim > this "saves over 2 lives"! --ok, maybe I am an old fogy, but in my day, essentially every programmer as a student had to implement some multiprecision arithmetic as homework. Are there 100,000 such students in the world? Easily. And multiprecision arithmetic was not an "incredibly rare" idea. It is so common and important that textbooks explain how to do it (Knuth) as a large fraction of said textbook. It is so common that many languages provide it, e.g. Scheme, built in. That is how en
Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?
On 29 July 2016 at 16:25, Jeff Law wrote: >> Well, if libiberty is going to be replaced en masse by gnulib, then >> there's no sense in me cleaning up libiberty's regex. libiberty cannot be replaced completely, because there are bits that do not even exist in gnulib. And given the time frame, I don't think Ayush will have time to replace all functions that already exist in gnulib. This will need to be an incremental process. What I expect to achieve is that we never need to re-implement in libiberty any function that already exists in gnulib. >> Before I spend any more time on this, is there a plan to review Ayush's >> work for say GCC 7? I obviously only care about regex* right now, or >> any alloca users in libiberty :). > > I'm not sure who's taking the lead on reviewing Ayush's work. But I do > expect someone will own it at some point in advance of stage1 close. It is mostly build system bits. We need a build-system reviewer (or a global reviewer). So far, Ayush haven't found any case that needs upstream (gnulib) or gcc-specific changes. Cheers, Manuel
Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?
On Fri, 29 Jul 2016, Manuel López-Ibáñez wrote: > On 29 July 2016 at 16:25, Jeff Law wrote: > >> Well, if libiberty is going to be replaced en masse by gnulib, then > >> there's no sense in me cleaning up libiberty's regex. > > libiberty cannot be replaced completely, because there are bits that > do not even exist in gnulib. And given the time frame, I don't think The relevant question (long-term) is not whether they exist now in gnulib, but whether equivalent functionality exists in or would be appropriate to add to gnulib. If gnulib has something equivalent with a different interface, migrating to that interface might be appropriate. And if it has nothing equivalent, adding the libiberty code to gnulib might be appropriate. -- Joseph S. Myers jos...@codesourcery.com
Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?
On Fri, Jul 29, 2016 at 1:44 PM, Joseph Myers wrote: > On Fri, 29 Jul 2016, Manuel López-Ibáñez wrote: > >> On 29 July 2016 at 16:25, Jeff Law wrote: >> >> Well, if libiberty is going to be replaced en masse by gnulib, then >> >> there's no sense in me cleaning up libiberty's regex. >> >> libiberty cannot be replaced completely, because there are bits that >> do not even exist in gnulib. And given the time frame, I don't think > > The relevant question (long-term) is not whether they exist now in gnulib, > but whether equivalent functionality exists in or would be appropriate to > add to gnulib. > > If gnulib has something equivalent with a different interface, migrating > to that interface might be appropriate. And if it has nothing equivalent, > adding the libiberty code to gnulib might be appropriate. gnulib does not have any support for the simple-object API to read and write object files in different file formats. - David
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
Let's imagine we have a 4-bit type, called nibble.
sizeof(nibble) == 1, because you can't have an object with a smaller size.
nibble a[2];
sizeof(a) == 1;
Because otherwise there isn't much benefit.
So now we have a type which violates one of the core rules of the type
system. sizeof(nibble[2 * N]) != 2 * sizeof(nibble[N])
That means any generic code that works with arbitrary types doesn't
work with this type.
This also breaks various idioms:
nibble b[3];
for(int i=0; i < sizeof(b)/sizeof(b[0]); ++i)
...
This loop doesn't visit all the elements.
Given a pointer to an array of nibbles and a length, how do I iterate
through the array?
void do_something(nibble* p);
int sum (nibble* p, size_t n) {
while (n)
do_something(p+n);
}
Pointer arithmetic won't work, because you can't address half a byte.
What is the address of p[n-1] ? You can't know, without knowing if p
points to the first or second nibble in a byte.
C does not naturally work with objects smaller than a byte (which
means the smallest addressable memory location, and is at least 8 bits
but might be more). They can exist as bit fields inside other objects,
but not in isolation.
To use such types it's is much cleaner to define an abstraction layer
that does the packing, masking, extracting etc. for you. Either a set
of functions that work with a pointer to some buffer, into which 4-bit
values are stored, or a C++ class that gives the appearance of a
packed array of 4-bit types but is implemented as a buffer of bytes.
But I suggested that right at the start of the thread and you
dismissed it (incorrectly saying it required C++, which is nonsense).
// A double nibble
struct nibnib {
signed char n1 : 4;
signed char n2 : 4;
};
inline signed char nib_get1(const nibnib* n) { return n->n1; }
inline signed char nib_get2(const nibnib* n) { return n->n2; }
inline void nib_set1(nibnib* n, signed char v) { n->n1 = v; }
inline void nib_set2(nibnib* n, signed char v) { n->n2 = v; }
Now this works naturally with the C object model. An array of "double
nibbles" is addressable and its size follows the usual rules, and it's
packed efficiently (optimally if CHAR_BIT == 8). There's no reason
this would be any less efficient than if it was supported natively by
the compiler, because it's going to have to do all the same operations
whether they are done through an API like this or implicitly by the
compiler. Using the API avoids having a weird type that doesn't obey
the rules of the language.
If it's as simple to implement as you think, and the unsuitability for
the C object model isn't a problem, maybe you should implement it
yourself, or pay someone to do it. Demanding that other people do it
for you when they clearly think it won't work is not going to succeed.
Alternatively, make a proposal to add this to ISO C, then if it gets
standardised GCC will support it. We don't just as non-standard
extensions because of one pushy person sending incredibly long emails.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 7/29/16, Jonathan Wakely wrote:
> Let's imagine we have a 4-bit type, called nibble.
>
> sizeof(nibble) == 1, because you can't have an object with a smaller size.
>
> nibble a[2];
> sizeof(a) == 1;
>
> Because otherwise there isn't much benefit.
--bitsizeof() is required.
> So now we have a type which violates one of the core rules of the type
> system. sizeof(nibble[2 * N]) != 2 * sizeof(nibble[N])
--by the way, it is spelled "nybble." Just like 8-bit objects
are not called a "bite." If you are reading "bite magazine" you are probably
in a different area. And the reason that commonly-used words
like nybble and byte were coined, is these are common concepts, in common use.
Not an ultra-rare concept hardly ever used, like
some people have utterly ridiculously asserted.
> That means any generic code that works with arbitrary types doesn't
> work with this type.
--But C does not support generic code per se.
> This also breaks various idioms:
>
> nibble b[3];
> for(int i=0; i < sizeof(b)/sizeof(b[0]); ++i)
> ...
>
> This loop doesn't visit all the elements.
--if you want to use stupid idioms, you will have bugs.
If you wanted to be smart about it, you use some sort of bitsizeof() which
should have been what C provided in the first place.
> Given a pointer to an array of nibbles and a length, how do I iterate
> through the array?
for(i=0; i void do_something(nibble* p);
> int sum (nibble* p, size_t n) {
> while (n)
> do_something(p+n);
> }
>
> Pointer arithmetic won't work, because you can't address half a byte.
> What is the address of p[n-1] ? You can't know, without knowing if p
> points to the first or second nibble in a byte.
--pointers would either have to be forbidden for subbyte objects, or
would have to be implemented in a way involving, e.g., a shift if necessary.
For example, the 7th bit inside a byte -- well 3 extra bits of
address are needed to know which bit it is, so which byte is address>>3,
and which bit is address&7.
By the way, on some machines I think this already happens, not to
address bits and nybbles, but to address bytes. Did anybody moan that
on such machines, "bytes are unaddressable"? And therefore unusable
in C? If and when anybody ever moaned that, then people like you told
them they were idiots, and you implemented the right tuff to do it
inside GCC. Undoubtably therefore, the needed code for my suggestion
already is inside GCC, merely with a few numbers changed.
> C does not naturally work with objects smaller than a byte (which
> means the smallest addressable memory location, and is at least 8 bits
> but might be more). They can exist as bit fields inside other objects,
> but not in isolation.
--other languages like Pascal managed to address these "unaddressable" objects,
to use the bogus word one of my critics branded them with.
> To use such types it's is much cleaner to define an abstraction layer
> that does the packing, masking, extracting etc. for you. Either a set
> of functions that work with a pointer to some buffer, into which 4-bit
> values are stored, or a C++ class that gives the appearance of a
> packed array of 4-bit types but is implemented as a buffer of bytes.
> But I suggested that right at the start of the thread and you
> dismissed it (incorrectly saying it required C++, which is nonsense).
>
> // A double nibble
> struct nibnib {
> signed char n1 : 4;
> signed char n2 : 4;
> };
> inline signed char nib_get1(const nibnib* n) { return n->n1; }
> inline signed char nib_get2(const nibnib* n) { return n->n2; }
> inline void nib_set1(nibnib* n, signed char v) { n->n1 = v; }
> inline void nib_set2(nibnib* n, signed char v) { n->n2 = v; }
>
> Now this works naturally with the C object model. An array of "double
> nibbles" is addressable and its size follows the usual rules, and it's
> packed efficiently (optimally if CHAR_BIT == 8). There's no reason
> this would be any less efficient than if it was supported natively by
> the compiler, because it's going to have to do all the same operations
> whether they are done through an API like this or implicitly by the
> compiler. Using the API avoids having a weird type that doesn't obey
> the rules of the language.
--sigh. It can certainly be done "manually" in ways like you here suggest.
Then you get ugly code that looks way different from the same code for bytes.
Then I have to write two programs not one program, basically, the two
appearing quite different, to do the same stuff for bytes and nybbles.
That makes it way more likely
I create a bug, and makes it unappetizing to read and check the code(s).
> Alternatively, make a proposal to add this to ISO C, then if it gets
> standardised GCC will support it. We don't just as non-standard
> extensions because of one pushy person sending incredibly long emails.
The way ISO C seems to happen, is some compilers implement the idea as
C extensions, then they see the light that it was a good idea and is
popular; then hence mak
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> Given a pointer to an array of nibbles and a length, how do I iterate > through the array? for(i=0; ihttp://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 29 July 2016 at 20:01, Warren D Smith wrote: >> Given a pointer to an array of nibbles and a length, how do I iterate >> through the array? > > for(i=0; i > --correction, that was for an array of packed bools. For nybbles, > bitsizeof(a)/4. There are various games one can play, and quibbles one > can make, all of which should have been so blitheringly obvious it > should not have ever been necessary to have this discussion at all. Maybe you should stop and discuss it somewhere else then. > Similarly, when some twerp complained > x=mul(a,b) > would be unacceptable because "mul" was too likely to be a name > already used by somebody... seriously? You're really unable to figure > out how to deal with that > without me telling you? > > It just boggles my mind that this stuff comes back at me for hours and hours. Funny, I was thinking the same thing.
