- User Since
- Jul 2 2015, 4:54 AM (155 w, 3 d)
- Mailing List
May 4 2018
Woops. Submitted that last comment too early. Editing it on Phab.
I think you and Richard agreed that you weren’t going to synthesize a whole
expression tree at every use of the operator, and I agree with that
decision. That’s very different from what I’m asking you to do, which is to
synthesize in isolation a call to the copy-constructor. There are several
places in the compiler that require these implicit copies which aren’t just
normal expressions; this is the common pattern for handling them. The
synthesized expression can be emitted multiple times, and it can be freely
re-synthesized in different translation units instead of being serialized.
You’re already finding and caching a constructor; storing a
CXXConstructExpr is basically thr same thing, but in a nicer form that
handles more cases and doesn’t require as much redundant code in IRGen.
Mar 14 2018
Mar 8 2018
Jul 11 2016
Jul 5 2016
We will add it. Thanks.
Jun 29 2016
We need to benchmark this to see if it still makes a difference.
Jun 23 2016
The returned pointer should point to the same pointee type as the argument. Header file cannot guarantee that.
Jun 1 2016
May 5 2016
This would be a great conversation to have at the social, sadly I will
have to miss it this month.
Apr 25 2016
Apr 13 2016
Sure, I'll take a look.
Apr 4 2016
Mar 21 2016
Just wanted to check if there are existing test cases for format::getStyle.
If there is no test for it, I'll add test cases for sure :=)
Mar 18 2016
+Lang, because he was asking me recently about this improvement & thinking
of chipping in
Mar 17 2016
I know that MIPS does that, and an out-of-tree implementation of hexagon
implements 1-byte cmpxchg in terms of the 4-byte version. The emulation
code isn't particularly small, and it seems reasonable to make it a
libcall. The emulation code seems sketchy from a correctness
perspective, as you end up generating unsolicited loads and stores on
adjacent bytes. Take a look at the thread on cfe-dev and llvm-dev named
"the as-if rule / perf vs. security" for some of the ramifications and
concerns surrounding unsolicited loads and stores.
Mar 14 2016
Mar 11 2016
Hi Aaron, Hi Juergen,
Feb 22 2016
Feb 9 2016
It's best not to commit things without approval once they've been sent for
review (the assumption being that if you asked for review it's because the
change needed review - time doesn't change that fact) - if approval was
given off-list (eg: on IRC) it's best to mention who gave it & where (&
ideally the person should provide it on-list just for record keeping)
Jan 25 2016
Given your follow-up review, and the behaviour of
match_results::operator, do you still have reservations?
Thanks for working on this!
Jan 22 2016
I'll upload a new patch in a moment. Replies inline below.
Jan 14 2016
I agree what you said about different code generated with clang and GCC
generates. In this case, we should throw an error (err_late_asm_label).
Jan 8 2016
Dec 7 2015
Nov 4 2015
Would citing PR20455 help? It wasn't actually my primary motivation but it's not too far off. Having the template parameters there lets you know what's going on in the DWARF, without having to fetch and parse the name string of every struct you come across. Actually I'm not sure parsing the name string is unambiguous either; each parameter is either a typename, or an expression, but without the parameter DIEs you don't know which, a-priori. (What does <foo> mean? Depends on whether you think it should be a type name or a value; you can't tell, syntactically, you have to do some lookups. Ah, but if you had the parameter DIEs, you would Just Know.)
Sep 8 2015
Aug 30 2015
@Aaron: Yes, I'm aware of that. I wanted to show that my check does not
take this into account.
Aug 26 2015
Aug 25 2015
Looks like the initial mail didn't hit the mailing list? Does someone want
to restart this review and/or forward that initial mail with the
Aug 21 2015
Aug 18 2015
I’m not sure how much people actually use these, but the AVX-512 versions of these, at least, can be very useful internally to implement AVX-512 intrinsics.
For AVX-512, we use the same GCC builtin for all 3 versions of the intrinsic (pass-through masked, set to zero masked, and unmasked). This is the same implementation that’s used in GCC, and is fairly clean, since the only difference is in the desired pass-through values (actual value, zero, or undef).