[gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL
Hi everyone, I'm trying to get the gimple * associated to the definition of a given var_decl. Basically, I am iterating over the locals of a function (through the local_decls member) and I need to be able to get the gimple * of its definition within the function's gimple_seq. Does any of you have an idea on how this could be achieved ? Thanks, Pierrick
Re: [gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL
On Tue, Jun 27, 2023 at 11:36 AM Pierrick Philippe wrote: > > Hi everyone, > > I'm trying to get the gimple * associated to the definition of a given > var_decl. > Basically, I am iterating over the locals of a function (through the > local_decls member) and I need to be able to get the gimple * of its > definition within the function's gimple_seq. > > Does any of you have an idea on how this could be achieved ? You need to walk the body of the function looking for defining stmts. Note the VAR_DECL might be in SSA form in which case you can also walk all SSA names and check those whose SSA_NAME_VAR is the specific VAR_DECL. But then SSA names can "lose" their associated decks so when a variable is in SSA form the set of original assignments cannot always be recovered easily. Richard. > Thanks, > > Pierrick >
Query status of GSoC project: CPyChecker
Hi Eric, I am Steven (now) from the CPython team. How is the project going? Do you have any prototypes or ideas that can be discussed? Which part will you start at? I recently debugged dozens of Python bugs, some involving C APIs. I can provide some test cases for you. For the ref count part: A major change (immortal objects) is introduced in Python 3.12. Basically, immortal objects will have the ref count fixed at a very large number (depending on `sizeof(void*)` ). But I don't think it is necessary to implement this in the early stages. Some stable API steals reference conditionally (on success), thus its behavior cannot be simply described by one attribute. For CPython versions: Some stable CPython API behavior varied across the minor release. (eg. 3.10 -> 3.11) For instance, some API accepted NULL as args for <3.8, but not >=3.8. Considering both "GCC" and "CPython" are hard for users to upgrade, we might want to consider how to live with these behavioral differences in the first place. Versions older than 3 minor releases cannot be touched. (3.13 now in active development, 3.12, 3.11 for bug fixes, 3.10, 3.9 security fixes only) So, versions <= 3.10 can be treated as frozen.
CLOBBER(eol)
I'm working on an updated version of my translation validator [*], and I
have some problems with CLOBBER(eol).
I currently treat CLOBBER(eol) as making the memory invalid (i.e. all
subsequent accesses is undefined behavior), but the tool reports
miscompilation for a few cases where the tree-nrv pass makes the IR
clobber by changing code such as [**]
union bu o;
...
o = i;
MEM[(union *)&o].b18 = _11;
MEM[(union *)&o].b20 = _11;
= o;
o ={v} {CLOBBER(eol)};
return ;
to use instead of o
union bu o [value-expr: ];
...
= i;
MEM[(union *)&].b18 = _11;
MEM[(union *)&].b20 = _11;
={v} {CLOBBER(eol)};
return ;
As a result, the tool therefore thinks the returned value is unavailable.
Is my understanding of CLOBBER(eol) correct? (I.e., is this a bug in
tree-nrv?) Or is special so that I should just ignore
CLOBBER(eol) for this case?
/Krister
[*] I'm planning to release the updated version in a few weeks. Meanwhile,
you can find the old version at https://github.com/kristerw/pysmtgcc
[**] This example originates from gcc.c-torture/execute/921204-1.c
compiled for x86 using the flags "-O -m32".
Re: CLOBBER(eol)
On Tue, Jun 27, 2023 at 12:07 PM Krister Walfridsson via Gcc
wrote:
>
> I'm working on an updated version of my translation validator [*], and I
> have some problems with CLOBBER(eol).
>
> I currently treat CLOBBER(eol) as making the memory invalid (i.e. all
> subsequent accesses is undefined behavior), but the tool reports
> miscompilation for a few cases where the tree-nrv pass makes the IR
> clobber by changing code such as [**]
>
>union bu o;
>...
>o = i;
>MEM[(union *)&o].b18 = _11;
>MEM[(union *)&o].b20 = _11;
> = o;
>o ={v} {CLOBBER(eol)};
>return ;
>
> to use instead of o
>
>union bu o [value-expr: ];
>...
> = i;
>MEM[(union *)&].b18 = _11;
>MEM[(union *)&].b20 = _11;
> ={v} {CLOBBER(eol)};
>return ;
>
> As a result, the tool therefore thinks the returned value is unavailable.
>
> Is my understanding of CLOBBER(eol) correct? (I.e., is this a bug in
> tree-nrv?) Or is special so that I should just ignore
> CLOBBER(eol) for this case?
I think this is a bug in NRV, yes, is special but the above would
allow to DSE the three stores.
Can you open a bugreport?
Thanks,
Richard.
>
> /Krister
>
>
> [*] I'm planning to release the updated version in a few weeks. Meanwhile,
> you can find the old version at https://github.com/kristerw/pysmtgcc
>
> [**] This example originates from gcc.c-torture/execute/921204-1.c
> compiled for x86 using the flags "-O -m32".
Re: CLOBBER(eol)
On Tue, 27 Jun 2023, Richard Biener wrote: I think this is a bug in NRV, yes, is special but the above would allow to DSE the three stores. Can you open a bugreport? Done! https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110434
Re: School Districts Contacts 2023
Hi there, We are excited to offer you a comprehensive email list of school districts that includes key contact information such as phone numbers, email addresses, mailing addresses, company revenue, size, and web addresses. Our databases also cover related industries such as: * K-12 schools * Universities * Vocational schools and training programs * Performing arts schools * Fitness centers and gyms * Child care services and providers * Educational publishers and suppliers If you're interested, we would be happy to provide you with relevant counts and a test file based on your specific requirements. Thank you for your time and consideration, and please let us know if you have any questions or concerns. Best regards, Nevaeh Rose To remove from this mailing reply with the subject line " LEAVE US".
Re: [gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL
On 27/06/2023 11:42, Richard Biener wrote: On Tue, Jun 27, 2023 at 11:36 AM Pierrick Philippe wrote: Hi everyone, I'm trying to get the gimple * associated to the definition of a given var_decl. Basically, I am iterating over the locals of a function (through the local_decls member) and I need to be able to get the gimple * of its definition within the function's gimple_seq. Does any of you have an idea on how this could be achieved ? You need to walk the body of the function looking for defining stmts. Note the VAR_DECL might be in SSA form in which case you can also walk all SSA names and check those whose SSA_NAME_VAR is the specific VAR_DECL. But then SSA names can "lose" their associated decks so when a variable is in SSA form the set of original assignments cannot always be recovered easily. Thank you for your answer Richard. I'll have a look into that. My main problem is regarding uninitialized definition, but still not being considered undefined behavior. For example, the following code: int x; int *y = &x; *y = 6; What I'm doing is basically looking at each gimple statement if the lhs has a given attribute for the purpose of the analysis I'm trying to perform. To precise, I'm plugged into the analyzer, so an out-of-tree plugin. But in the example above, the definition of x is not really within the gimple_seq of the function as it is never directly assigned. Pierrick Richard. Thanks, Pierrick
wishlist: support for shorter pointers
Hello everybody, I'm not quite sure if this is correct mailbox for this suggestion (may be "embedded" would be better), but let me present it first (and while the examples is from ARM stm32 environment, the issue would equally apply to i386 or even amd64). So: 1. Small MPU (like stm32f103) would normally have small amount of RAM, and even somewhat larger variant do have its memory "partitioned/ dedicated" to various subsystems (like CloseCoupledMemory, Ethernet buffers, USB buffs, etc). 2. to address any location within those sections of that memory (or their entire RAM) it would suffice to use 16-bit pointers. 3. still, declaring a pointer in GCC always allocate "natural" size of a pointer in given architecture. In case of ARM stm32 it would be 32-bits. 4. programs using pointers do keep them around in structures. So programs with heavy use of pointers have those structures like 2 times larger then necessary if only pointers were 16-bit. And memory in those devices is scarce. 5. the same thing applies to 64-bit world. Programs that don't require huge memories but do use pointers excessively, MUST take up 64-bit for a pointer no matter what. So I was wondering if it would be feasible for GCC to allow SEGMENT to be declared as "small" (like 16-bit addressable in 32-bit CPU, or 32-bit addressable in 64-bit CPU), and ANY pointer declared to reference location within them would then be appropriately reduced. In ARM world, the use of such pointers would require the use of an additional register (functionally being a "segment base address") to allow for data access using instructions like: "LD Rx, [Ry, Rz]" - meaning register index reference. Here Ry is the base of the SEGMENT in question. Or if (like inside a loop) the structure "pointed to" by Rz must be often used, just one operation "ADD Rz, Ry" will prep Rz for subsequent "ordinary" offset operations like: "LD Ra, [Rz, #member]" ... and reentering the loop by "LDH Rz, [Rz, #next]" does what's required by "x = x->next". Not having any experience in compiler implementations I have no idea if this is a big or a small change to compiler design. -R
Re: [gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL
Hello, On Tue, 27 Jun 2023, Pierrick Philippe wrote: > My main problem is regarding uninitialized definition, but still not being > considered undefined behavior. > For example, the following code: > >int x; >int *y = &x; >*y = 6; > > What I'm doing is basically looking at each gimple statement if the lhs has a > given attribute for the purpose of the analysis I'm trying to perform. > To precise, I'm plugged into the analyzer, so an out-of-tree plugin. > > But in the example above, the definition of x is not really within the > gimple_seq of the function as it is never directly assigned. Then you need to be a bit more precise in what exactly you want. There are multiple ways to interpret "definition of a variable". a) assigning a value to it: that's what Richard alluded to, you need to iterate all gimple statements to see if any assign to variables you're interested in (in SSA form there will only be one, outside SSA there may be many). As you notice there also may be none at all that directly assign a value. You need to solve the associated data-flow problem in order to (conservatively) know the answer to this question. In particular you need points-to sets (above for instance, that 'y' points to 'x' so that when you modify '*y' that you can note down that "whatever y points to (i.e. at least x) is modified"). There is no ready-made list of statements that potentially modify a local variable in question. You need to do that yourself, but GCC contains many helper routines for parts of this problem (as it needs to answer these questions itself as well, for optimization purposes). b) allocating storage for the variable in question (and possibly giving it an initial value): there are _no_ gimple instruction that express this idea. The very fact that variables are mentioned in local_decls (and are used in a meaningful way in the instruction stream) leads to them being allocated on the stack during function expansion (see expand_used_vars). non-local variables are similarly handled, they are placed in various lists that lead to appropriate assembler statements allocating static storage for them (in the data or bss, or whatever other appropriate, segment). They aren't defined (in the allocate-it sense) by gimple statement either. Ciao, Michael.
[PATCH] Basic asm blocks should always be volatile
gcc's documentatation mentions that all basic asm blocks are always volatile,
yet the parser fails to account for this by only ever setting
volatile_p to true
if the volatile qualifier is found. This patch fixes this by adding a
special case check for extended_p before finish_asm_statement is called
>From 3094be39e3e65a6a638f05fafd858b89fefde6b5 Mon Sep 17 00:00:00 2001
From: TheShermanTanker
Date: Tue, 27 Jun 2023 23:56:38 +0800
Subject: [PATCH] asm not using extended syntax should always be volatile
---
gcc/cp/parser.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index a6341b9..ef3d06a 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -22355,6 +22355,9 @@ cp_parser_asm_definition (cp_parser* parser)
/* Create the ASM_EXPR. */
if (parser->in_function_body)
{
+ if (!extended_p) {
+volatile_p = true;
+ }
asm_stmt = finish_asm_stmt (asm_loc, volatile_p, string, outputs,
inputs, clobbers, labels, inline_p);
/* If the extended syntax was not used, mark the ASM_EXPR. */
--
2.35.1.windows.2
Re: [PATCH] Basic asm blocks should always be volatile
My apologies, I sent this to the wrong list. I have already resent it to the correct one regards, Julian
Re: [PATCH] Basic asm blocks should always be volatile
On Tue, Jun 27, 2023 at 9:03 AM Julian Waters via Gcc wrote:
>
> gcc's documentatation mentions that all basic asm blocks are always volatile,
> yet the parser fails to account for this by only ever setting
> volatile_p to true
> if the volatile qualifier is found. This patch fixes this by adding a
> special case check for extended_p before finish_asm_statement is called
The patch which are you doing will not change the behavior of GCC as
GCC already treats them as volatile later on.
non-extended inline-asm has no outputs so the following code in the
gimplifier will kick in and turn the gimple statement into volatile:
gimple_asm_set_volatile (stmt, ASM_VOLATILE_P (expr) || noutputs == 0);
(note I am about to push a patch which changes the condition slightly
to have `asm goto` as volatile).
Thanks,
Andrew
>
> From 3094be39e3e65a6a638f05fafd858b89fefde6b5 Mon Sep 17 00:00:00 2001
> From: TheShermanTanker
> Date: Tue, 27 Jun 2023 23:56:38 +0800
> Subject: [PATCH] asm not using extended syntax should always be volatile
>
> ---
> gcc/cp/parser.cc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> index a6341b9..ef3d06a 100644
> --- a/gcc/cp/parser.cc
> +++ b/gcc/cp/parser.cc
> @@ -22355,6 +22355,9 @@ cp_parser_asm_definition (cp_parser* parser)
>/* Create the ASM_EXPR. */
>if (parser->in_function_body)
> {
> + if (!extended_p) {
> +volatile_p = true;
> + }
> asm_stmt = finish_asm_stmt (asm_loc, volatile_p, string, outputs,
> inputs, clobbers, labels, inline_p);
> /* If the extended syntax was not used, mark the ASM_EXPR. */
> --
> 2.35.1.windows.2
Re: [PATCH] Basic asm blocks should always be volatile
Hi Andrew,
That can't be right, on my system a test of asm vs asm volatile with -O3
and -flto=auto yields very different results, with only the latter being
correct. The patch fixed it and caused gcc to emit correct assembly
best regards,
Julian
On Wed, Jun 28, 2023 at 12:08 AM Andrew Pinski wrote:
> On Tue, Jun 27, 2023 at 9:03 AM Julian Waters via Gcc
> wrote:
> >
> > gcc's documentatation mentions that all basic asm blocks are always
> volatile,
> > yet the parser fails to account for this by only ever setting
> > volatile_p to true
> > if the volatile qualifier is found. This patch fixes this by adding a
> > special case check for extended_p before finish_asm_statement is called
>
> The patch which are you doing will not change the behavior of GCC as
> GCC already treats them as volatile later on.
> non-extended inline-asm has no outputs so the following code in the
> gimplifier will kick in and turn the gimple statement into volatile:
> gimple_asm_set_volatile (stmt, ASM_VOLATILE_P (expr) || noutputs ==
> 0);
>
> (note I am about to push a patch which changes the condition slightly
> to have `asm goto` as volatile).
>
> Thanks,
> Andrew
>
> >
> > From 3094be39e3e65a6a638f05fafd858b89fefde6b5 Mon Sep 17 00:00:00 2001
> > From: TheShermanTanker
> > Date: Tue, 27 Jun 2023 23:56:38 +0800
> > Subject: [PATCH] asm not using extended syntax should always be volatile
> >
> > ---
> > gcc/cp/parser.cc | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> > index a6341b9..ef3d06a 100644
> > --- a/gcc/cp/parser.cc
> > +++ b/gcc/cp/parser.cc
> > @@ -22355,6 +22355,9 @@ cp_parser_asm_definition (cp_parser* parser)
> >/* Create the ASM_EXPR. */
> >if (parser->in_function_body)
> > {
> > + if (!extended_p) {
> > +volatile_p = true;
> > + }
> > asm_stmt = finish_asm_stmt (asm_loc, volatile_p, string, outputs,
> > inputs, clobbers, labels, inline_p);
> > /* If the extended syntax was not used, mark the ASM_EXPR. */
> > --
> > 2.35.1.windows.2
>
Re: [PATCH] Basic asm blocks should always be volatile
Perhaps this only affects compilation when GIMPLE isn't being used?
On Wed, Jun 28, 2023 at 12:15 AM Julian Waters
wrote:
> Hi Andrew,
>
> That can't be right, on my system a test of asm vs asm volatile with -O3
> and -flto=auto yields very different results, with only the latter being
> correct. The patch fixed it and caused gcc to emit correct assembly
>
> best regards,
> Julian
>
> On Wed, Jun 28, 2023 at 12:08 AM Andrew Pinski wrote:
>
>> On Tue, Jun 27, 2023 at 9:03 AM Julian Waters via Gcc
>> wrote:
>> >
>> > gcc's documentatation mentions that all basic asm blocks are always
>> volatile,
>> > yet the parser fails to account for this by only ever setting
>> > volatile_p to true
>> > if the volatile qualifier is found. This patch fixes this by adding a
>> > special case check for extended_p before finish_asm_statement is called
>>
>> The patch which are you doing will not change the behavior of GCC as
>> GCC already treats them as volatile later on.
>> non-extended inline-asm has no outputs so the following code in the
>> gimplifier will kick in and turn the gimple statement into volatile:
>> gimple_asm_set_volatile (stmt, ASM_VOLATILE_P (expr) || noutputs ==
>> 0);
>>
>> (note I am about to push a patch which changes the condition slightly
>> to have `asm goto` as volatile).
>>
>> Thanks,
>> Andrew
>>
>> >
>> > From 3094be39e3e65a6a638f05fafd858b89fefde6b5 Mon Sep 17 00:00:00 2001
>> > From: TheShermanTanker
>> > Date: Tue, 27 Jun 2023 23:56:38 +0800
>> > Subject: [PATCH] asm not using extended syntax should always be volatile
>> >
>> > ---
>> > gcc/cp/parser.cc | 3 +++
>> > 1 file changed, 3 insertions(+)
>> >
>> > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
>> > index a6341b9..ef3d06a 100644
>> > --- a/gcc/cp/parser.cc
>> > +++ b/gcc/cp/parser.cc
>> > @@ -22355,6 +22355,9 @@ cp_parser_asm_definition (cp_parser* parser)
>> >/* Create the ASM_EXPR. */
>> >if (parser->in_function_body)
>> > {
>> > + if (!extended_p) {
>> > +volatile_p = true;
>> > + }
>> > asm_stmt = finish_asm_stmt (asm_loc, volatile_p, string, outputs,
>> > inputs, clobbers, labels, inline_p);
>> > /* If the extended syntax was not used, mark the ASM_EXPR. */
>> > --
>> > 2.35.1.windows.2
>>
>
Re: [PATCH] Basic asm blocks should always be volatile
On Tue, Jun 27, 2023 at 9:15 AM Julian Waters wrote:
>
> Hi Andrew,
>
> That can't be right, on my system a test of asm vs asm volatile with -O3 and
> -flto=auto yields very different results, with only the latter being correct.
> The patch fixed it and caused gcc to emit correct assembly
Can you provide a few testcases? Because the gimplifier should always happen.
Thanks,
Andrew Pinski
>
> best regards,
> Julian
>
> On Wed, Jun 28, 2023 at 12:08 AM Andrew Pinski wrote:
>>
>> On Tue, Jun 27, 2023 at 9:03 AM Julian Waters via Gcc
>> wrote:
>> >
>> > gcc's documentatation mentions that all basic asm blocks are always
>> > volatile,
>> > yet the parser fails to account for this by only ever setting
>> > volatile_p to true
>> > if the volatile qualifier is found. This patch fixes this by adding a
>> > special case check for extended_p before finish_asm_statement is called
>>
>> The patch which are you doing will not change the behavior of GCC as
>> GCC already treats them as volatile later on.
>> non-extended inline-asm has no outputs so the following code in the
>> gimplifier will kick in and turn the gimple statement into volatile:
>> gimple_asm_set_volatile (stmt, ASM_VOLATILE_P (expr) || noutputs == 0);
>>
>> (note I am about to push a patch which changes the condition slightly
>> to have `asm goto` as volatile).
>>
>> Thanks,
>> Andrew
>>
>> >
>> > From 3094be39e3e65a6a638f05fafd858b89fefde6b5 Mon Sep 17 00:00:00 2001
>> > From: TheShermanTanker
>> > Date: Tue, 27 Jun 2023 23:56:38 +0800
>> > Subject: [PATCH] asm not using extended syntax should always be volatile
>> >
>> > ---
>> > gcc/cp/parser.cc | 3 +++
>> > 1 file changed, 3 insertions(+)
>> >
>> > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
>> > index a6341b9..ef3d06a 100644
>> > --- a/gcc/cp/parser.cc
>> > +++ b/gcc/cp/parser.cc
>> > @@ -22355,6 +22355,9 @@ cp_parser_asm_definition (cp_parser* parser)
>> >/* Create the ASM_EXPR. */
>> >if (parser->in_function_body)
>> > {
>> > + if (!extended_p) {
>> > +volatile_p = true;
>> > + }
>> > asm_stmt = finish_asm_stmt (asm_loc, volatile_p, string, outputs,
>> > inputs, clobbers, labels, inline_p);
>> > /* If the extended syntax was not used, mark the ASM_EXPR. */
>> > --
>> > 2.35.1.windows.2
Re: [PATCH] Basic asm blocks should always be volatile
On Tue, Jun 27, 2023 at 9:16 AM Julian Waters wrote:
>
> Perhaps this only affects compilation when GIMPLE isn't being used?
The only time GIMPLE is not used is if you supply -fsyntax-only so ...
Thanks,
Andrew
>
> On Wed, Jun 28, 2023 at 12:15 AM Julian Waters
> wrote:
>>
>> Hi Andrew,
>>
>> That can't be right, on my system a test of asm vs asm volatile with -O3 and
>> -flto=auto yields very different results, with only the latter being
>> correct. The patch fixed it and caused gcc to emit correct assembly
>>
>> best regards,
>> Julian
>>
>> On Wed, Jun 28, 2023 at 12:08 AM Andrew Pinski wrote:
>>>
>>> On Tue, Jun 27, 2023 at 9:03 AM Julian Waters via Gcc
>>> wrote:
>>> >
>>> > gcc's documentatation mentions that all basic asm blocks are always
>>> > volatile,
>>> > yet the parser fails to account for this by only ever setting
>>> > volatile_p to true
>>> > if the volatile qualifier is found. This patch fixes this by adding a
>>> > special case check for extended_p before finish_asm_statement is called
>>>
>>> The patch which are you doing will not change the behavior of GCC as
>>> GCC already treats them as volatile later on.
>>> non-extended inline-asm has no outputs so the following code in the
>>> gimplifier will kick in and turn the gimple statement into volatile:
>>> gimple_asm_set_volatile (stmt, ASM_VOLATILE_P (expr) || noutputs ==
>>> 0);
>>>
>>> (note I am about to push a patch which changes the condition slightly
>>> to have `asm goto` as volatile).
>>>
>>> Thanks,
>>> Andrew
>>>
>>> >
>>> > From 3094be39e3e65a6a638f05fafd858b89fefde6b5 Mon Sep 17 00:00:00 2001
>>> > From: TheShermanTanker
>>> > Date: Tue, 27 Jun 2023 23:56:38 +0800
>>> > Subject: [PATCH] asm not using extended syntax should always be volatile
>>> >
>>> > ---
>>> > gcc/cp/parser.cc | 3 +++
>>> > 1 file changed, 3 insertions(+)
>>> >
>>> > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
>>> > index a6341b9..ef3d06a 100644
>>> > --- a/gcc/cp/parser.cc
>>> > +++ b/gcc/cp/parser.cc
>>> > @@ -22355,6 +22355,9 @@ cp_parser_asm_definition (cp_parser* parser)
>>> >/* Create the ASM_EXPR. */
>>> >if (parser->in_function_body)
>>> > {
>>> > + if (!extended_p) {
>>> > +volatile_p = true;
>>> > + }
>>> > asm_stmt = finish_asm_stmt (asm_loc, volatile_p, string, outputs,
>>> > inputs, clobbers, labels, inline_p);
>>> > /* If the extended syntax was not used, mark the ASM_EXPR. */
>>> > --
>>> > 2.35.1.windows.2
Re: wishlist: support for shorter pointers
I want to preface this stating that I have little to no experience in compiler development, I am only merely just getting into it. With that said, I have messed around with library design a fair amount, and this seems like something that could be implemented in a library. It might be slightly comfier implemented on the compiler side, but I question how generally it could be implemented. >In ARM world, the use of such pointers would require the use of an >additional register (functionally being a "segment base address") to >allow for data access using instructions like: "LD Rx, [Ry, Rz]" - >meaning register index reference. What you say here makes me feel like you should just be implementing this in library. With how you're describing it, it seems like the compiler would have no idea what the "segment base address" would actually be without additional annotation. Since you would need that annotation anyway, it seems best implemented in library. I think what you want to do (for 16 bit pointers) is have a struct that internally is a fixed width 16 bit uint, and have an operator* that sets up the registers for that particular segment. It would be a bit of an implementation task since you have to do some inline ASM, but thats just the reality of implementing low level libraries. Like I said before, and unless I'm mistaken, since the segments would need annotations anyway, it probably makes the most sense to implement this in library as I'm describing. I believe these types would be referred to as "fancy pointers." Hopefully I'm not too mistaken as I don't have any experience with this field. In general though, I believe that if something can be implemented in a reasonable way in library, then it belongs in library, not in language or other extensions. -Alex
