[llvm-dev] SROA and volatile memcpy/memset

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> To: "Chandler Carruth" <chandlerc at gmail.com>, "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvm-dev at lists.llvm.org
> Sent: Wednesday, November 11, 2015 9:34:01 AM
> Subject: Re: [llvm-dev] SROA and volatile memcpy/memset
> 
> On 11/11/2015 9:28 AM, Chandler Carruth wrote:
> > So, here is the model that LLVM is using: a volatile memcpy is
> > lowered
> > to a loop of loads and stores of indeterminate width. As such,
> > splitting
> > a memcpy is always valid.
> >
> > If we want a very specific load and store width for volatile
> > accesses, I
> > think that the frontend should generate concrete loads and stores
> > of a
> > type with that width. Ultimately, memcpy is a pretty bad model for
> > *specific* width accesses, it is best at handling indeterminate
> > sized
> > accesses, which is exactly what doesn't make sense for device
> > backed
> > volatile accesses.
> >
> 
> Yeah, the remark about devices I made in my post was a result of a
> "last-minute" thought to add some rationale.  It doesn't actually
> apply
> to SROA, since there are no devices that are mapped to the stack,
> which
> is what SROA is interested in.
> 
> The concern with the testcase I attached is really about performance.
> Would it be reasonable to control the splitting in SROA via TTI?

How so?

 -Hal

> 
> -Krzysztof
> 
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory