Displaying 4 results from an estimated 4 matches for "loadpre".
Did you mean:
loadparm
2017 Mar 09
4
[RFC] bitfield access shrinking
...ementation in D30416 only supports load-and-or-store
pattern matching, and it uses a inst-by-inst scan as a safety check to
make sure there is no other memory write insn between the load and
store (no alias query is done). After getting the initial
implementation, we found more problems: EarlyCSE, LoadPRE and even
InstCombine itself can do coalescing before the shrinking (LoadPRE
does it the most thoroughly).
The coalescing can move the load many BasicBlocks earlier and make
simple inst-by-inst scan unscalable and oftentimes fail. It also
breaks the load-and-or-store pattern. An example is below:
B...
2017 Mar 09
4
[RFC] bitfield access shrinking
...oad-and-or-store
>> pattern matching, and it uses a inst-by-inst scan as a safety check to
>> make sure there is no other memory write insn between the load and
>> store (no alias query is done). After getting the initial
>> implementation, we found more problems: EarlyCSE, LoadPRE and even
>> InstCombine itself can do coalescing before the shrinking (LoadPRE
>> does it the most thoroughly).
>> The coalescing can move the load many BasicBlocks earlier and make
>> simple inst-by-inst scan unscalable and oftentimes fail. It also
>> breaks the load-...
2017 Mar 09
3
[RFC] bitfield access shrinking
...oad-and-or-store
>> pattern matching, and it uses a inst-by-inst scan as a safety check to
>> make sure there is no other memory write insn between the load and
>> store (no alias query is done). After getting the initial
>> implementation, we found more problems: EarlyCSE, LoadPRE and even
>> InstCombine itself can do coalescing before the shrinking (LoadPRE
>> does it the most thoroughly).
>> The coalescing can move the load many BasicBlocks earlier and make
>> simple inst-by-inst scan unscalable and oftentimes fail. It also
>> breaks the load-...
2015 Jan 08
8
[LLVMdev] Separating loop nests based on profile information?
On 01/07/2015 05:33 PM, Chandler Carruth wrote:
> How does this compare with classical approaches of loop peeling,
> partitioning, fission, or whatever you might call it?
I'm still developing a good sense for this, but let me lay out some
observations. Fair warning, this is going to be long and rambling.
Let's start with a toy example:
while(c) {
x = this->x;
y =