Thanks for the reply! I see you point. Indeed, I've also seen cases
where the
load pipeline was overused at the beginning of a basic block, whereas at
the end
the code got stuck with a bunch of stores and no other instructions to
run in
parallel. And indeed, relaxing the restrictions makes thing
On 13/09/15 20:19, Florian Weimer wrote:
> * Jeff Law:
>
>> On 09/13/2015 12:28 PM, Florian Weimer wrote:
>>> * Ajit Kumar Agarwal:
>>>
The replacement of malloc with alloca can be done on the following
analysis.
If the lifetime of an object does not stretch beyond the immediat
On Sun, 13 Sep 2015, Ajit Kumar Agarwal wrote:
The replacement of malloc with alloca can be done on the following analysis.
If the lifetime of an object does not stretch beyond the immediate scope. In
such cases the malloc can be replaced with alloca.
This increases the performance to a great
On 09/14/2015 02:14 AM, Richard Earnshaw wrote:
On 13/09/15 20:19, Florian Weimer wrote:
* Jeff Law:
On 09/13/2015 12:28 PM, Florian Weimer wrote:
* Ajit Kumar Agarwal:
The replacement of malloc with alloca can be done on the following
analysis.
If the lifetime of an object does not stretc
> You would need some way to indicate that while Y does accept a mem,
> this particular mem can't be reloaded to match. We don't have a way
> to do that.
As a test, I added this API. It seems to work. I suppose there could
be a better API where we determine if a constrain matches various
memor
On Mon, Sep 14, 2015 at 11:05 PM, DJ Delorie wrote:
> As a test, I added this API. It seems to work. I suppose there could
> be a better API where we determine if a constrain matches various
> memory spaces, then compare with the memory space of the operand, but
> I can't prove that's sufficient
