• msg-28891-85.txt159 B

  Download

We will add it. Thanks.

We need to benchmark this to see if it still makes a difference.

The returned pointer should point to the same pointee type as the argument. Header file cannot guarantee that.

• msg-22400-127.txt159 B

  Download

This would be a great conversation to have at the social, sadly I will
have to miss it this month.

• msg-15757-444.txt159 B

  Download

Sure, I'll take a look.
Thanks!

• msg-21051-113.txt159 B

  Download

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 :=)

+Lang, because he was asking me recently about this improvement & thinking
of chipping in

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.

Friendly PING.

Hi Aaron, Hi Juergen,

• msg-30393-176.txt159 B

  Download

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)

Given your follow-up review, and the behaviour of
match_results::operator[], do you still have reservations?

Thanks for working on this!

I'll upload a new patch in a moment. Replies inline below.

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).

• msg-516-145.txt159 B

  Download

• msg-25712-156.txt159 B

  Download

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.)

Hi Sean,

@Aaron: Yes, I'm aware of that. I wanted to show that my check does not
take this into account.

• msg-12340-169.txt159 B

  Download

• msg-32543-315.txt159 B

  Download

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
patch/description/etc?

• msg-1588-168.txt159 B

  Download

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).