> I meant "anti-commutativity"; sorry about the mixup.
symmetry/antisymmetry is more appropriate for binary relations (commutativity
is for binary operations).
--
Eric Botcazou
On Fri, May 11, 2018 at 03:03:09PM +0300, Alexander Monakov wrote:
> On Fri, 11 May 2018, Segher Boessenkool wrote:
> > > In general such address-based comparisons steps are invalid; they lack
> > > anti-reflexivity. So comparators are not actually allowed to do that.
> >
> > I don't know what you
On Fri, 11 May 2018, Segher Boessenkool wrote:
> > In general such address-based comparisons steps are invalid; they lack
> > anti-reflexivity. So comparators are not actually allowed to do that.
>
> I don't know what you mean here? Every comparator is required to be
> *reflexive*! Subtracting t
On Fri, May 11, 2018 at 01:35:00PM +0300, Alexander Monakov wrote:
> On Fri, 11 May 2018, Segher Boessenkool wrote:
> > For example from reload1.c:
>
> No, this example is not relevant, because ...
>
> > static int
> > reload_reg_class_lower (const void *r1p, const void *r2p)
> > {
> > int r1 =
On Fri, May 11, 2018 at 05:29:05AM -0500, Segher Boessenkool wrote:
> Such a comparator will still work with temporary arrays if both elements
> are always in the same temp array (in deterministic order, etc.) array; but
> it won't work if the comparator did e.g.
>
> return (r1 - reload_order) -
On Fri, 11 May 2018, Segher Boessenkool wrote:
> For example from reload1.c:
No, this example is not relevant, because ...
> static int
> reload_reg_class_lower (const void *r1p, const void *r2p)
> {
> int r1 = *(const short *) r1p, r2 = *(const short *) r2p;
>
> // ...
>
> return r1 - r2;
On Thu, May 10, 2018 at 07:40:57PM +0200, Richard Biener wrote:
> On May 10, 2018 5:56:39 PM GMT+02:00, Alexander Monakov
> wrote:
> >/* This implements a sort function suitable for GCC use cases:
> > - signature-compatible to C qsort, but relaxed contract:
> > - may apply the comparator to
On Thu, 10 May 2018, Richard Biener wrote:
> > - signature-compatible to C qsort, but relaxed contract:
> > - may apply the comparator to elements in a temporary buffer
>
> What consequences has this or rather how is this observable and makes
> comparators behave differently?
The only ser
On Thu, 10 May 2018, Jakub Jelinek wrote:
> Have you gathered some statistics on the element sizes and how often they
> appear in qsort calls (perhaps weighted by n*log(n) of the element count)
> across bootstrap+regtest?
No, but Adhemerval Zanella collected stats on bootstrap, and they are simila
On May 10, 2018 5:56:39 PM GMT+02:00, Alexander Monakov
wrote:
>Hello.
>
>This introduces a replacement for qsort() in GCC. The main selling
>point is
>reproducibility (currently compiler output may change depending on how
>libc
>qsort reorders not-bitwise-identical elements that compare equal) w
On Thu, May 10, 2018 at 06:56:39PM +0300, Alexander Monakov wrote:
> Overall the new implementation is roughly 30% faster compared to Glibc qsort,
> with 2x or more speedup for cases with tiny element count. I see one instance
> where the new approach is significantly (1.5x) slower: it is ipa-icf.c
Hello.
This introduces a replacement for qsort() in GCC. The main selling point is
reproducibility (currently compiler output may change depending on how libc
qsort reorders not-bitwise-identical elements that compare equal) with a
small improvement speed-wise and small code growth (under 2K on x
12 matches
Mail list logo
