[PATCH] D28920: DAG: Allow targets to override stack temp alignment

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D28920#659064, @arsenm wrote:

> In https://reviews.llvm.org/D28920#657526, @hfinkel wrote:
>
> > In https://reviews.llvm.org/D28920#657029, @arsenm wrote:
> >
> > > In https://reviews.llvm.org/D28920#656702, @hfinkel wrote:
> > >
> > > > Unless you'd like to extend stack temps to be put in other address spaces, isn't that a frontend issue (i.e. applies only to globals)?
> > >
> > >
> > > This is something I would like to be able to do someday (but I think this would be purely a codegen problem, so wouldn't need to be seen the in the IR).
> >
> >
> > Does your backend maintain multiple stacks (e.g. some kind of "global stack" and a "local stack")? Does this depend on some non-recursion analysis? [I'm really curious what you're thinking here - not only does it affect this patch, but it also potentially affects discussions I've been having about OpenMP accelerator semantics].
>
>
> Not really. Local memory doesn't behave like a stack and is just a block of memory allocated for the workgroup for the entire program. Accessing private memory is much slower, so in some cases for spills and small stack objects we could potentially optimize by writing them there instead. We don't support calls currently, and OpenCL explicitly forbids recursion so I haven't spent much time worrying about that.


Makes sense ;)

To come back to your original question, I'd think that you'd want to extend DataLayout to support per-address-space alignments in that case, just like we have per-address-space pointer sizes. You'd want this  at the IR-level too.


https://reviews.llvm.org/D28920