- User Since
- Nov 16 2012, 6:02 PM (256 w, 4 d)
Sun, Oct 15
Thu, Oct 12
Wed, Oct 11
Please upload a patch with full context.
Tue, Oct 10
Mon, Oct 9
Sat, Oct 7
Some suggested improvements to the English in the documentation...
Fri, Oct 6
Thu, Oct 5
Can you explain briefly what is required of the system in order to support this (is it just ifunc support in the dynamic linker / loader)?
Wed, Oct 4
This is a minimal patch to solve PR34603:
Tue, Oct 3
Rebased (and fixed address mappings for (big-Endian) ppc64).
LGTM too. Please do update the test so it checks that the result makes sense. We need more test coverage in this area.
Mon, Oct 2
Is this still being worked on?
Sun, Oct 1
Sat, Sep 30
Fri, Sep 29
Please also add a C++ test to check the mangling-related features.
Unfortunately, when you submit a patch for review, you need to add the commits list for the associated project as a subscriber. As this patch has no subscribers, no one saw it. While you can add a subscriber now, that won't send out the patch summary again. As a result, it's best to abandon this review and start another one. Make sure that you add cfe-commits as a subscriber, and the patch will get reviewed. Also, feel free to add me as a reviewer.
LGTM (but please run performance tests and a self-host check before committing - I can imagine us overlooking something here).
Wed, Sep 27
Maybe we should do this in follow-up, but I'd also like to see some general text added to the LangRef about the semantics of loops (that makes reference to this intrinsic). Maybe we can say something like:
Yes, I see this sounds more reasonable indeed. Btw, currently LLVM can remove convergent in some cases to recover the performance loss?
Tue, Sep 26
I apologize for taking so long to get back to this. The bit-permutation selector uses a cost model to decide how to lower each permutation sequence. Preemptively lowering the zext like this during the analysis phase of the algorithm seems suboptimal (or at least ad hoc).
You seem to be only changing the behavior for the "separatable" fields, but I suspect you want to change the behavior for the others too. The bitfield would be decomposed into shards, separated by the naturally-sized-and-aligned fields. Each access only loads its shard. For example, in your test case you have:
Mon, Sep 25
Fri, Sep 22
Thu, Sep 21
I think this generally looks fine.
Wed, Sep 20
Any performance changes in the test suite?