Philip Reames via llvm-dev
2019-Jul-31 16:15 UTC
[llvm-dev] [RFC] Changing X86 data layout for address spaces
Please review the properties of an address space which are configurable via the data layout. For example, bitwidth is one of those parameters. If that parameter space covers your needs, then you do not need LLVM side support. Philip On 7/30/19 2:59 PM, Amy Huang wrote:> Thanks for the info-- > It seems like the way to do this is for clang to use address spaces to > represent different sized pointers in the IR. If that's the case, then > LLVM still has to know about those specific address spaces. I don't > see a clear way to avoid adding knowledge of the address spaces to LLVM. > I think that's the approach we'll go with, unless there are more > objections. > > On Sun, Jul 28, 2019 at 8:23 AM John Reagan > <john.reagan at vmssoftware.com <mailto:john.reagan at vmssoftware.com>> wrote: > > That is basically what we do today to provide mixed sized pointers > with > our legacy frontends. They generate IR to our old code generator > which > has ADDR32 and ADDR64 datatypes. We use a 64-bit address data layout > and then typecast the 32-bit forms to/from the underlying 64-bit > addresses. I have been warned that such rampant typecasting might > interfere with certain optimizations or TBAA data. We haven't > investigated that yet. Since clang doesn't go through our IR-to-IR > converter, we'll have to teach clang to do the same. > > On 7/26/2019 6:35 PM, Amy Huang wrote: > > *Clang* can assign whatever meaning to an AS it wishes, > and their > > properties are configurable via data layout configuration. > > > > > > I think Clang checks that its data layout matches the LLVM > target data > > layout, so I'm not sure how to go about implementing the address > spaces > > as a change in Clang. > > Thoughts? > > > > The other issue I was running into is how to do the address > space casts > > in clang - my current thought was to lower the address space > casts in > > LLVM to the sign extension / zero extension / truncation. > > > > Thanks, > > Amy > > > > On Mon, Jul 22, 2019 at 5:06 PM Philip Reames via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> > wrote: > > > > Please don't bake in knowledge *in LLVM* of a address space > unless > > there's a strong need. *Clang* can assign whatever meaning > to an AS > > it wishes, and their properties are configurable via data layout > > configuration. > > > > The standards of review are much lower for a Clang only > change as it > > can be revised arbitrarily without breaking other uses of LLVM. > > Building in first class knowledge to LLVM itself is a breaking > > change (potentially) for other frontends. > > > > Philip > > > > On 7/22/19 1:19 PM, Reid Kleckner via llvm-dev wrote: > >> Yes, the address spaces are intended to be generally useful for > >> other applications. Glad to hear that you would find it > useful. :) > >> > >> For now we were only going to add them for x86, but it > should be > >> easy to add such address spaces to other targets. > >> > >> On Mon, Jul 22, 2019 at 1:13 PM John Reagan via llvm-dev > >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> > wrote: > >> > >> Amy, when you say "implement MSVC's extensions", is that > >> MSVC/LLVM or > >> are you going to add these to clang? OpenVMS has > dual-sized > >> pointers as > >> well and want to see them in clang. One of my engineers > >> noticed that > >> address space 4 was a 32-bit pointer address space (or at > >> least it used > >> to be). I haven't seen any formal discussion of that > over in > >> the cfe > >> dev list. I'm happy to help out where we can. > >> > >> John > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190731/c490a75e/attachment.html>
Arsenault, Matthew via llvm-dev
2019-Jul-31 16:26 UTC
[llvm-dev] [RFC] Changing X86 data layout for address spaces
The datalayout itself is currently not considered a point of configurability. It’s a static, backend/codegen defined property. The target machine machine returns the datalayout for the given triple and is the source of truth. The front end is responsible for creating a module with an exactly matching datalayout and is not free to customize the datalayout this way. I’m not sure what there is to gain by avoiding putting this information in the backend. -Matt ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> Sent: Wednesday, July 31, 2019 12:15 To: Amy Huang; John Reagan Cc: llvm-dev Subject: Re: [llvm-dev] [RFC] Changing X86 data layout for address spaces Please review the properties of an address space which are configurable via the data layout. For example, bitwidth is one of those parameters. If that parameter space covers your needs, then you do not need LLVM side support. Philip On 7/30/19 2:59 PM, Amy Huang wrote: Thanks for the info-- It seems like the way to do this is for clang to use address spaces to represent different sized pointers in the IR. If that's the case, then LLVM still has to know about those specific address spaces. I don't see a clear way to avoid adding knowledge of the address spaces to LLVM. I think that's the approach we'll go with, unless there are more objections. On Sun, Jul 28, 2019 at 8:23 AM John Reagan <john.reagan at vmssoftware.com<mailto:john.reagan at vmssoftware.com>> wrote: That is basically what we do today to provide mixed sized pointers with our legacy frontends. They generate IR to our old code generator which has ADDR32 and ADDR64 datatypes. We use a 64-bit address data layout and then typecast the 32-bit forms to/from the underlying 64-bit addresses. I have been warned that such rampant typecasting might interfere with certain optimizations or TBAA data. We haven't investigated that yet. Since clang doesn't go through our IR-to-IR converter, we'll have to teach clang to do the same. On 7/26/2019 6:35 PM, Amy Huang wrote:> *Clang* can assign whatever meaning to an AS it wishes, and their > properties are configurable via data layout configuration. > > > I think Clang checks that its data layout matches the LLVM target data > layout, so I'm not sure how to go about implementing the address spaces > as a change in Clang. > Thoughts? > > The other issue I was running into is how to do the address space casts > in clang - my current thought was to lower the address space casts in > LLVM to the sign extension / zero extension / truncation. > > Thanks, > Amy > > On Mon, Jul 22, 2019 at 5:06 PM Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>> wrote: > > Please don't bake in knowledge *in LLVM* of a address space unless > there's a strong need. *Clang* can assign whatever meaning to an AS > it wishes, and their properties are configurable via data layout > configuration. > > The standards of review are much lower for a Clang only change as it > can be revised arbitrarily without breaking other uses of LLVM. > Building in first class knowledge to LLVM itself is a breaking > change (potentially) for other frontends. > > Philip > > On 7/22/19 1:19 PM, Reid Kleckner via llvm-dev wrote: >> Yes, the address spaces are intended to be generally useful for >> other applications. Glad to hear that you would find it useful. :) >> >> For now we were only going to add them for x86, but it should be >> easy to add such address spaces to other targets. >> >> On Mon, Jul 22, 2019 at 1:13 PM John Reagan via llvm-dev >> <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>> wrote: >> >> Amy, when you say "implement MSVC's extensions", is that >> MSVC/LLVM or >> are you going to add these to clang? OpenVMS has dual-sized >> pointers as >> well and want to see them in clang. One of my engineers >> noticed that >> address space 4 was a 32-bit pointer address space (or at >> least it used >> to be). I haven't seen any formal discussion of that over in >> the cfe >> dev list. I'm happy to help out where we can. >> >> John >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190731/b70fdd0a/attachment.html>
Reid Kleckner via llvm-dev
2019-Jul-31 16:31 UTC
[llvm-dev] [RFC] Changing X86 data layout for address spaces
On Wed, Jul 31, 2019 at 9:26 AM Arsenault, Matthew via llvm-dev < llvm-dev at lists.llvm.org> wrote:> The datalayout itself is currently not considered a point of > configurability. It’s a static, backend/codegen defined property. The > target machine machine returns the datalayout for the given triple and is > the source of truth. The front end is responsible for creating a module > with an exactly matching datalayout and is not free to customize the > datalayout this way. I’m not sure what there is to gain by avoiding putting > this information in the backend. >I agree with everything here, but did you mean frontend instead of backend in the last sentence? As a consequence of the fact that each target defines its data layout, that means we have to put the new data layout in the backend and the frontend if we are going to use address spaces. We could implement this purely in the frontend with ptrotoint / inttoptr, zext, sext, trunc, i32, i64 etc, but the IR for it is quite awful and unoptimizable. It breaks several invariants and the extension seems to be naturally representable with address spaces. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190731/183fac9d/attachment.html>
Philip Reames via llvm-dev
2019-Jul-31 17:28 UTC
[llvm-dev] [RFC] Changing X86 data layout for address spaces
Looks like I made my point in an accidentally really confusing way. Let me try again w/Matt's correction in mind. I want to make sure that the middle end optimizer code is *driven by the data layout*. I am not trying to express an opinion on how that data layout is populated (frontend, backedge, black magic, what have you). I just want to make sure that we don't end with the middle end having to know that address space "56" has special meaning beyond what is encoded in the data layout. To say it differently, I want to make sure that a different frontend targeting a different backend is not effected by the proposed changes. Philip On 7/31/19 9:26 AM, Arsenault, Matthew wrote:> The datalayout itself is currently not considered a point of > configurability. It’s a static, backend/codegen defined property. The > target machine machine returns the datalayout for the given triple and > is the source of truth. The front end is responsible for creating a > module with an exactly matching datalayout and is not free to > customize the datalayout this way. I’m not sure what there is to gain > by avoiding putting this information in the backend. > > -Matt > > ------------------------------------------------------------------------ > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Philip > Reames via llvm-dev <llvm-dev at lists.llvm.org> > *Sent:* Wednesday, July 31, 2019 12:15 > *To:* Amy Huang; John Reagan > *Cc:* llvm-dev > *Subject:* Re: [llvm-dev] [RFC] Changing X86 data layout for address > spaces > > Please review the properties of an address space which are > configurable via the data layout. For example, bitwidth is one of > those parameters. If that parameter space covers your needs, then you > do not need LLVM side support. > > Philip > > On 7/30/19 2:59 PM, Amy Huang wrote: >> Thanks for the info-- >> It seems like the way to do this is for clang to use address spaces >> to represent different sized pointers in the IR. If that's the case, >> then LLVM still has to know about those specific address spaces. I >> don't see a clear way to avoid adding knowledge of the address spaces >> to LLVM. >> I think that's the approach we'll go with, unless there are more >> objections. >> >> On Sun, Jul 28, 2019 at 8:23 AM John Reagan >> <john.reagan at vmssoftware.com <mailto:john.reagan at vmssoftware.com>> wrote: >> >> That is basically what we do today to provide mixed sized >> pointers with >> our legacy frontends. They generate IR to our old code generator >> which >> has ADDR32 and ADDR64 datatypes. We use a 64-bit address data layout >> and then typecast the 32-bit forms to/from the underlying 64-bit >> addresses. I have been warned that such rampant typecasting might >> interfere with certain optimizations or TBAA data. We haven't >> investigated that yet. Since clang doesn't go through our IR-to-IR >> converter, we'll have to teach clang to do the same. >> >> On 7/26/2019 6:35 PM, Amy Huang wrote: >> > *Clang* can assign whatever meaning to an AS it wishes, >> and their >> > properties are configurable via data layout configuration. >> > >> > >> > I think Clang checks that its data layout matches the LLVM >> target data >> > layout, so I'm not sure how to go about implementing the >> address spaces >> > as a change in Clang. >> > Thoughts? >> > >> > The other issue I was running into is how to do the address >> space casts >> > in clang - my current thought was to lower the address space >> casts in >> > LLVM to the sign extension / zero extension / truncation. >> > >> > Thanks, >> > Amy >> > >> > On Mon, Jul 22, 2019 at 5:06 PM Philip Reames via llvm-dev >> > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> <mailto:llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>>> wrote: >> > >> > Please don't bake in knowledge *in LLVM* of a address space >> unless >> > there's a strong need. *Clang* can assign whatever meaning >> to an AS >> > it wishes, and their properties are configurable via data >> layout >> > configuration. >> > >> > The standards of review are much lower for a Clang only >> change as it >> > can be revised arbitrarily without breaking other uses of >> LLVM. >> > Building in first class knowledge to LLVM itself is a breaking >> > change (potentially) for other frontends. >> > >> > Philip >> > >> > On 7/22/19 1:19 PM, Reid Kleckner via llvm-dev wrote: >> >> Yes, the address spaces are intended to be generally >> useful for >> >> other applications. Glad to hear that you would find it >> useful. :) >> >> >> >> For now we were only going to add them for x86, but it >> should be >> >> easy to add such address spaces to other targets. >> >> >> >> On Mon, Jul 22, 2019 at 1:13 PM John Reagan via llvm-dev >> >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> <mailto:llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>>> wrote: >> >> >> >> Amy, when you say "implement MSVC's extensions", is that >> >> MSVC/LLVM or >> >> are you going to add these to clang? OpenVMS has >> dual-sized >> >> pointers as >> >> well and want to see them in clang. One of my engineers >> >> noticed that >> >> address space 4 was a 32-bit pointer address space (or at >> >> least it used >> >> to be). I haven't seen any formal discussion of that >> over in >> >> the cfe >> >> dev list. I'm happy to help out where we can. >> >> >> >> John >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190731/3b5a5b9a/attachment.html>