Zac Hansen via llvm-dev
2016-Jul-26 23:02 UTC
[llvm-dev] [PATCH] Add support for the 'unless' matcher in the dynamic layer.
Even if it still did add overhead, it seems perfectly reasonable, from a
user's perspective (namely mine), that if I introduce unnecessary narrowing
matchers to my chain that there may be a performance penalty.
The ability to do the following easily outweighs any performance issues for
me:
anyOf (
/* hasName("..."), */
hasName("...")
)
though C++ not allowing trailing commas makes this not quite as great.
*However, without help, I would not be able to put forward a patch with
anything more than simply removing the minimums.*
Would this be acceptable or would someone be able to point me at what it
would take to do it the "smart way" in less time than it would take
them to
make the change themselves?
On Tue, Jul 26, 2016 at 3:29 PM, Samuel Benzaquen <sbenza at google.com>
wrote:
> One of the reasons we added the minimum was because these nodes added
> overhead to the matching that was not unnecessary when they only had a
> single node.
> On the current implementation we could actually get rid of the node
> completely for the one argument calls.
> I would be ok with removing the lower bound.
>
>
> On Tue, Jul 26, 2016 at 6:20 PM, Zac Hansen <xaxxon at gmail.com>
wrote:
>
>> I was wondering if there is any objection to removing the 2-element
>> minimum on the eachOf, anyOf and allOf matchers.
>>
>> It is frustrating when playing with matchers to have to edit
significant
>> amounts of code to be able to temporarily go from 2 to 1 matcher inside
an
>> any- or allOf matcher.
>>
>> And overall it feels very "un-set-theory"-like.
>>
>> The change was made here:
>>
https://github.com/llvm-mirror/clang/commit/674e54c167eab0be7a54bca7082c07d2f1d0c8cc
>>
>>
>> Thank you and apologies if I sent this to the wrong lists/people.
>>
>> --Zac
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160726/8b7f3b73/attachment.html>
Piotr Padlewski via llvm-dev
2016-Jul-26 23:06 UTC
[llvm-dev] [PATCH] Add support for the 'unless' matcher in the dynamic layer.
We could also just add nothing() matcher, so debugging would be much easier, just add anything() or nothing() matcher as extra argument. The other pros of it is that new developers won't send the patches that uses those variadic matchers with only one argument. 2016-07-26 16:02 GMT-07:00 Zac Hansen via llvm-dev <llvm-dev at lists.llvm.org> :> Even if it still did add overhead, it seems perfectly reasonable, from a > user's perspective (namely mine), that if I introduce unnecessary narrowing > matchers to my chain that there may be a performance penalty. > > The ability to do the following easily outweighs any performance issues > for me: > > > anyOf ( > /* hasName("..."), */ > hasName("...") > > ) > > though C++ not allowing trailing commas makes this not quite as great. > > > *However, without help, I would not be able to put forward a patch with > anything more than simply removing the minimums.* > > Would this be acceptable or would someone be able to point me at what it > would take to do it the "smart way" in less time than it would take them to > make the change themselves? > > On Tue, Jul 26, 2016 at 3:29 PM, Samuel Benzaquen <sbenza at google.com> > wrote: > >> One of the reasons we added the minimum was because these nodes added >> overhead to the matching that was not unnecessary when they only had a >> single node. >> On the current implementation we could actually get rid of the node >> completely for the one argument calls. >> I would be ok with removing the lower bound. >> >> >> On Tue, Jul 26, 2016 at 6:20 PM, Zac Hansen <xaxxon at gmail.com> wrote: >> >>> I was wondering if there is any objection to removing the 2-element >>> minimum on the eachOf, anyOf and allOf matchers. >>> >>> It is frustrating when playing with matchers to have to edit significant >>> amounts of code to be able to temporarily go from 2 to 1 matcher inside an >>> any- or allOf matcher. >>> >>> And overall it feels very "un-set-theory"-like. >>> >>> The change was made here: >>> https://github.com/llvm-mirror/clang/commit/674e54c167eab0be7a54bca7082c07d2f1d0c8cc >>> >>> >>> Thank you and apologies if I sent this to the wrong lists/people. >>> >>> --Zac >>> >> >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160726/d2f3c869/attachment.html>
Manuel Klimek via llvm-dev
2016-Jul-27 10:40 UTC
[llvm-dev] [PATCH] Add support for the 'unless' matcher in the dynamic layer.
On Wed, Jul 27, 2016 at 1:06 AM Piotr Padlewski via llvm-dev < llvm-dev at lists.llvm.org> wrote:> We could also just add nothing() matcher, so debugging would be much > easier, just add anything() or nothing() matcher as extra argument. > > The other pros of it is that new developers won't send the patches that > uses those variadic matchers with only one argument. >We already have anything() and unless(anything()).> > 2016-07-26 16:02 GMT-07:00 Zac Hansen via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Even if it still did add overhead, it seems perfectly reasonable, from a >> user's perspective (namely mine), that if I introduce unnecessary narrowing >> matchers to my chain that there may be a performance penalty. >> >> The ability to do the following easily outweighs any performance issues >> for me: >> >> >> anyOf ( >> /* hasName("..."), */ >> hasName("...") >> >> ) >> >> though C++ not allowing trailing commas makes this not quite as great. >> >> >> *However, without help, I would not be able to put forward a patch with >> anything more than simply removing the minimums.* >> >> Would this be acceptable or would someone be able to point me at what it >> would take to do it the "smart way" in less time than it would take them to >> make the change themselves? >> >> On Tue, Jul 26, 2016 at 3:29 PM, Samuel Benzaquen <sbenza at google.com> >> wrote: >> >>> One of the reasons we added the minimum was because these nodes added >>> overhead to the matching that was not unnecessary when they only had a >>> single node. >>> On the current implementation we could actually get rid of the node >>> completely for the one argument calls. >>> I would be ok with removing the lower bound. >>> >>> >>> On Tue, Jul 26, 2016 at 6:20 PM, Zac Hansen <xaxxon at gmail.com> wrote: >>> >>>> I was wondering if there is any objection to removing the 2-element >>>> minimum on the eachOf, anyOf and allOf matchers. >>>> >>>> It is frustrating when playing with matchers to have to edit >>>> significant amounts of code to be able to temporarily go from 2 to 1 >>>> matcher inside an any- or allOf matcher. >>>> >>>> And overall it feels very "un-set-theory"-like. >>>> >>>> The change was made here: >>>> https://github.com/llvm-mirror/clang/commit/674e54c167eab0be7a54bca7082c07d2f1d0c8cc >>>> >>>> >>>> Thank you and apologies if I sent this to the wrong lists/people. >>>> >>>> --Zac >>>> >>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160727/fca9d73b/attachment.html>