Re: Request for discussion: Rewrite of inline assembler docs
dw writes:
> Using this clobber causes the compiler to flush all (modified) registers
> being used to store memory-based values to memory before executing the
> @code{asm} statement. Further, the compiler will not assume that any
> memory-based values read before the @code{asm} will remain unchanged
> after the @code{asm}; it will reload them as needed. This effectively
> forms a read/write memory barrier for the compiler. For performance
> reasons, some variables only exist in registers and never get written to
> memory. The "memory" clobber does not force these values to get written
> to memory.
Sounds good to me.
> Anything else?
Nope, that's it :-)
Thanks,
Richard
Re: Request for discussion: Rewrite of inline assembler docs
On 03/28/2014 06:20 AM, dw wrote:
> Using this clobber causes the compiler to flush all (modified) registers
> being used to store memory-based values to memory before executing the
> @code{asm} statement.
I don't know what a "memory-based" value is. This phrase doesn't help
at all. In addition, it isn't true. Modified registers are not
flushed to memory unless they are clobbered or their address is taken.
This sentence should be deleted.
Andrew.
int sum(int a[], int l) {
int i;
int sum = 0;
for (i = 0; i < l; i++) {
asm volatile("nop # Nothing at all":::"memory");
sum += a[i];
}
return sum;
}
at -O2:
sum:
.LFB0:
.cfi_startproc
xorl%eax, %eax
testl %esi, %esi
jle .L3
subl$1, %esi
xorl%edx, %edx
leaq4(,%rsi,4), %rcx
.p2align 4,,10
.p2align 3
.L4:
#APP
# 5 "z.c" 1
nop # Nothing at all
# 0 "" 2
#NO_APP
addl(%rdi,%rdx), %eax
addq$4, %rdx
cmpq%rcx, %rdx
jne .L4
.L3:
rep
ret
Re: Request for discussion: Rewrite of inline assembler docs
On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
> On 03/28/2014 06:20 AM, dw wrote:
> > Using this clobber causes the compiler to flush all (modified) registers
> > being used to store memory-based values to memory before executing the
> > @code{asm} statement.
>
> I don't know what a "memory-based" value is. This phrase doesn't help
> at all. In addition, it isn't true. Modified registers are not
> flushed to memory unless they are clobbered or their address is taken.
> This sentence should be deleted.
i and sum form your example are not allocated in memory. If you make
one of them static you should be able to see the effect.
Bye,
Hannes
Re: Request for discussion: Rewrite of inline assembler docs
On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
> On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
>> On 03/28/2014 06:20 AM, dw wrote:
>>> Using this clobber causes the compiler to flush all (modified) registers
>>> being used to store memory-based values to memory before executing the
>>> @code{asm} statement.
>>
>> I don't know what a "memory-based" value is. This phrase doesn't help
>> at all. In addition, it isn't true. Modified registers are not
>> flushed to memory unless they are clobbered or their address is taken.
>> This sentence should be deleted.
>
> i and sum form your example are not allocated in memory. If you make
> one of them static you should be able to see the effect.
I know. That's not the point. "memory-based" is not a well-defined
term. In order to write clear documentation it is necessary either to
define terms or to use terms that are already well-defined.
What is true here is that all registers used to cache variables that
are reachable from pointers in the program are flushed. Anything that
is statically allocated is reachable, as is anything dynamically
allocated by malloc; auto variables are not reachable unless their
address is taken.
Andrew.
Re: question regarding new warning
On 27 March 2014 23:37, Daniel Gutson wrote: >> >> There are some known bugs in -Wconversion and nobody working on them, >> so if you are still interested in helping, I can give you some hints >> on where your help will be very welcome. > > Could you please go ahead and show me the failing cases? > I only worked in the backend, but I'd like to take a look to the front-end. Two "easy" ones: http://gcc.gnu.org/PR55096 about converting 'false' to bool *. http://gcc.gnu.org/PR60591 about unsafe enum conversions There are more, but they are a bit more complicated. If you feel brave enough, let me know. > There's also all the other commenters of my post regarding the =- and > =+ looking-like operators, which should take ws into account. > I think it would be a good idea to have a warning for =- and =+ saying something like: test.c:4:8: warning: suggested space between '=' and '-' to avoid confusion with operator '-=' x =- 4; ^ Clang already warns about this: test.c:4:7: warning: use of unary operator that may be intended as compound assignment (+=) x =+ 4; ^~ I think this should be easy to implement during parsing for both C and C++, so you may want to start with this one. Cheers, Manuel.
Re: Request for discussion: Rewrite of inline assembler docs
On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
> On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
> > On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
> >> On 03/28/2014 06:20 AM, dw wrote:
> >>> Using this clobber causes the compiler to flush all (modified) registers
> >>> being used to store memory-based values to memory before executing the
> >>> @code{asm} statement.
> >>
> >> I don't know what a "memory-based" value is. This phrase doesn't help
> >> at all. In addition, it isn't true. Modified registers are not
> >> flushed to memory unless they are clobbered or their address is taken.
> >> This sentence should be deleted.
> >
> > i and sum form your example are not allocated in memory. If you make
> > one of them static you should be able to see the effect.
>
> I know. That's not the point. "memory-based" is not a well-defined
> term. In order to write clear documentation it is necessary either to
> define terms or to use terms that are already well-defined.
Ok, I see the problem. Maybe something like this by avoiding the term?
Using this clobber causes the compiler to flush all (modified) registers
being used to store values which gcc decided to originally allocate in
memory before executing the @code{asm} statement.
> What is true here is that all registers used to cache variables that
> are reachable from pointers in the program are flushed. Anything that
> is statically allocated is reachable, as is anything dynamically
> allocated by malloc; auto variables are not reachable unless their
> address is taken.
One would have to go into detail of various optimizations which could
remove the address taking e.g. IMHO the last sentence of the paragraph already
deals with this.
Bye,
Hannes
Re: Request for discussion: Rewrite of inline assembler docs
On 28-Mar-14 01:46 PM, Hannes Frederic Sowa wrote:
On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
Ok, I see the problem. Maybe something like this by avoiding the term?
Using this clobber causes the compiler to flush all (modified)
registers being used to store values which gcc decided to originally
allocate in memory before executing the @code{asm} statement.
What is true here is that all registers used to cache variables that
are reachable from pointers in the program are flushed. Anything that
is statically allocated is reachable, as is anything dynamically
allocated by malloc; auto variables are not reachable unless their
address is taken.
One would have to go into detail of various optimizations which could
remove the address taking e.g. IMHO the last sentence of the paragraph already
deals with this.
Bye,
Hannes
By this wording (gcc decided), the consequences are unpredictable. You
should probably mention the registers which will definitely be flushed
and thereby limit the ambiguity.
Re: Request for discussion: Rewrite of inline assembler docs
On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
> On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
>> On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
>>> On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
On 03/28/2014 06:20 AM, dw wrote:
> Using this clobber causes the compiler to flush all (modified) registers
> being used to store memory-based values to memory before executing the
> @code{asm} statement.
I don't know what a "memory-based" value is. This phrase doesn't help
at all. In addition, it isn't true. Modified registers are not
flushed to memory unless they are clobbered or their address is taken.
This sentence should be deleted.
>>>
>>> i and sum form your example are not allocated in memory. If you make
>>> one of them static you should be able to see the effect.
>>
>> I know. That's not the point. "memory-based" is not a well-defined
>> term. In order to write clear documentation it is necessary either to
>> define terms or to use terms that are already well-defined.
>
> Ok, I see the problem. Maybe something like this by avoiding the term?
>
> Using this clobber causes the compiler to flush all (modified) registers
> being used to store values which gcc decided to originally allocate in
> memory before executing the @code{asm} statement.
Not really, no: that's not true.
>> What is true here is that all registers used to cache variables that
>> are reachable from pointers in the program are flushed. Anything that
>> is statically allocated is reachable, as is anything dynamically
>> allocated by malloc; auto variables are not reachable unless their
>> address is taken.
>
> One would have to go into detail of various optimizations which could
> remove the address taking
One would not: any such optimization would be incorrect. Any memory
reachable from an inline asm statement with a memory clobber must
be flushed to memory.
> e.g. IMHO the last sentence of the paragraph already
> deals with this.
Which last sentence of what paragraph?
Andrew.
Re: Testing machine descriptions
Thanks for the info. I will try it out. On Fri, Mar 28, 2014 at 12:07 AM, Senthil Kumar Selvaraj wrote: > On Thu, Mar 27, 2014 at 07:51:06PM -0400, Niranjan Hasabnis wrote: >> Hi DJ Delorie, >> >> Thank you for your answer. It is useful. One more question: so does the >> main testsuite cover all md entries? Meaning all possible assembly >> instructions that could be generated by that md are checked by the >> main testsuite? Thank you again. >> > > You can check it out yourself - just build gcc with coverage > instrumentation turned on, and then use gcov. > > http://tryout.senthilthecoder.com/view/coverage/gcc/config/avr/avr.md.gcov.html > shows coverage information for the AVR target's md file. > > Regards > Senthil -- -- Regards, Niranjan Hasabnis.
Some Tests in gcc.dg/graphite/ are failing for AVR target
Hi all, Some of the tests added in gcc.dg/graphite are failing for AVR target, Because size of the arrays defined are 'too' large for AVR. I'm wondering is it possible to reduce the size of the array's in tests. One example is gcc.dg/graphite/scop-0.c, which is failing with error "size of array 'a' is too large" when compiling with avr-gcc. Following tests are also failing for avr-gcc with error "size of array used is too large". gcc.dg/graphite/scop-22.c gcc.dg/graphite/scop-3.c gcc.dg/graphite/scop-dsyr2k.c gcc.dg/graphite/scop-dsyrk.c gcc.dg/graphite/scop-mvt.c gcc.dg/graphite/scop-sor.c gcc.dg/graphite/pr46185.c Regards Vishnu KS
C Code in GCC Machine Descriptions
Hello everyone,
I am Saswat Padhi, a final year undergraduate at IIT Bombay, India.
With help from the GCC Resource Center here, I am currently investing
possible improvements to GCC Machine Descriptions, with a goal of
making them concise and composable.
One of the improvements we were looking at is, reducing the C code
fragments within the define_expand constructs in the machine
descriptions. In some of the define_expands we observed that the C
code fragments implement the same checks which can equivalently be
achieved through the use of constraints. So, we thought that
introducing constraints-validation at the expander level could be
useful. An example of change we are proposing, is illustrated below:
(define_expand "movsi"
[(set (match_operand:SI 0 "nonimmediate_operand" "")
(match_operand:SI 1 "general_operand" "")
)]
""
{ if(GET_CODE(operands[0])==MEM && GET_CODE(operands[1])!=REG)
{ if(can_create_pseudo_p())
{ operands[1]=force_reg(SImode,operands[1]); }
}})
With the expander handling the constraints, the above define_expand
can be written as:
(define_expand "movsi"
[(set (match_operand:SI 0 "nonimmediate_operand" "=r,m,r,r")
(match_operand:SI 1 "general_operand" "r,r,i,m")
)]
""
)
This concise define_expand expression would achieve the desired effect
because when the first operand matches the second constraint
alternative [m], the second operand would be force_reg into the second
alternative [r]. All other cases are also explicitly mentioned as
alternative constraints.
As a first step towards this, I prepared this report
(https://docs.google.com/document/d/1Yb5b3-r4YfxEL0omvAqqGFGIYLLeMenn-EHQvSHgKUw/edit)
which is a survey of the define_expand expressions in i386 and MIPS
machine descriptions. But as the report explains, the results of the
survey do not appear in our favor. We see very few define_expands
where we can actually replace some parts of the C code by introducing
constraint validation in the expander.
I seek feedback from the community regarding:
1. Is the idea is worth pursuing? In other words, would we be able to
reduce significant amount of C code from the GCC MDs by introducing
constraint validation at expander?
2. If answer to (1) is yes, do the parameters mentioned in the report
make sense? We use 3 parameters to estimate whether we would be able
to simplify a define_expand by removing at least a part of the C code.
3. If the answer to (2) is yes, why don't we see any gain in i386 and
MIPS MDs? Then are there other cases where the gain would be
significant?
Thank you in advance for your time and help :-)
Re: Request for discussion: Rewrite of inline assembler docs
On Fri, Mar 28, 2014 at 03:03:11PM +, Andrew Haley wrote:
> On 03/28/2014 02:48 PM, Hannes Frederic Sowa wrote:
> > On Fri, Mar 28, 2014 at 01:15:39PM +, Andrew Haley wrote:
> >> On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
> >>> On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
> On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
> > On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
> >> On 03/28/2014 06:20 AM, dw wrote:
> >
> What is true here is that all registers used to cache variables that
> are reachable from pointers in the program are flushed. Anything that
> is statically allocated is reachable, as is anything dynamically
> allocated by malloc; auto variables are not reachable unless their
> address is taken.
> >>>
> >>> One would have to go into detail of various optimizations which could
> >>> remove the address taking
> >>
> >> One would not: any such optimization would be incorrect. Any memory
> >> reachable from an inline asm statement with a memory clobber must
> >> be flushed to memory.
> >
> > If I extend your example with an additional pointer and take the address of
> > s
> > it still doesn't allocate s in memory and as such cannot flush out the
> > register content, which is perfectly legal. The pointer is completley
> > eliminated (this is an extreme example).
> >
> > int sum(int a[], int l) {
> > int i;
> > int s = 0;
> > int *sp = &s;
> > for (i = 0; i < l; i++) {
> > asm volatile("nop # Nothing at all":::"memory");
> > *sp += a[i];
> > }
> > return s;
> > }
>
> But that's not reachable from the asm. Reachability is key here. The
> address of s is taken, but not used; GCC knows that it is not
> reachable.
>
> >>> e.g. IMHO the last sentence of the paragraph already
> >>> deals with this.
> >>
> >> Which last sentence of what paragraph?
> >
> > This one:
> >
> > | For performance reasons, some variables only exist in registers
> > | and never get written to memory. The "memory" clobber does not
> > | force these values to get written to memory.
>
> Except when it does; this is why the technical language has to be
> *precise*.
>
> The memory clobber will force all reachable variables into memory: it
> must.
>
> If we're going to avoid precise technical terms like "reachable" we
> have to find some other way of saying this, or not mention is at all.
> We must not say things that are misleading.
I guess I was confused with the term reachability, because I considered
stack values reachable regarding the inline assembler block, too.
Can one call that "symbolic reachability"? It would be great if the new
documentation could explain that, but I guess I am not the right person to
propose such a paragraph.
Bye,
Hannes
Re: Request for discussion: Rewrite of inline assembler docs
On Fri, Mar 28, 2014 at 01:15:39PM +, Andrew Haley wrote:
> On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
> > On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
> >> On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
> >>> On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
> On 03/28/2014 06:20 AM, dw wrote:
> > Using this clobber causes the compiler to flush all (modified)
> > registers
> > being used to store memory-based values to memory before executing the
> > @code{asm} statement.
>
> I don't know what a "memory-based" value is. This phrase doesn't help
> at all. In addition, it isn't true. Modified registers are not
> flushed to memory unless they are clobbered or their address is taken.
> This sentence should be deleted.
> >>>
> >>> i and sum form your example are not allocated in memory. If you make
> >>> one of them static you should be able to see the effect.
> >>
> >> I know. That's not the point. "memory-based" is not a well-defined
> >> term. In order to write clear documentation it is necessary either to
> >> define terms or to use terms that are already well-defined.
> >
> > Ok, I see the problem. Maybe something like this by avoiding the term?
> >
> > Using this clobber causes the compiler to flush all (modified) registers
> > being used to store values which gcc decided to originally allocate in
> > memory before executing the @code{asm} statement.
>
> Not really, no: that's not true.
Hmm, ok?
> >> What is true here is that all registers used to cache variables that
> >> are reachable from pointers in the program are flushed. Anything that
> >> is statically allocated is reachable, as is anything dynamically
> >> allocated by malloc; auto variables are not reachable unless their
> >> address is taken.
> >
> > One would have to go into detail of various optimizations which could
> > remove the address taking
>
> One would not: any such optimization would be incorrect. Any memory
> reachable from an inline asm statement with a memory clobber must
> be flushed to memory.
If I extend your example with an additional pointer and take the address of s
it still doesn't allocate s in memory and as such cannot flush out the
register content, which is perfectly legal. The pointer is completley
eliminated (this is an extreme example).
int sum(int a[], int l) {
int i;
int s = 0;
int *sp = &s;
for (i = 0; i < l; i++) {
asm volatile("nop # Nothing at all":::"memory");
*sp += a[i];
}
return s;
}
> > e.g. IMHO the last sentence of the paragraph already
> > deals with this.
>
> Which last sentence of what paragraph?
This one:
| For performance reasons, some variables only exist in registers and never
| get written to memory. The "memory" clobber does not force these values
| to get written to memory.
Btw. very nice work!
Thanks,
Hannes
Re: Request for discussion: Rewrite of inline assembler docs
On 03/28/2014 02:48 PM, Hannes Frederic Sowa wrote:
> On Fri, Mar 28, 2014 at 01:15:39PM +, Andrew Haley wrote:
>> On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
>>> On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
> On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
>> On 03/28/2014 06:20 AM, dw wrote:
>
What is true here is that all registers used to cache variables that
are reachable from pointers in the program are flushed. Anything that
is statically allocated is reachable, as is anything dynamically
allocated by malloc; auto variables are not reachable unless their
address is taken.
>>>
>>> One would have to go into detail of various optimizations which could
>>> remove the address taking
>>
>> One would not: any such optimization would be incorrect. Any memory
>> reachable from an inline asm statement with a memory clobber must
>> be flushed to memory.
>
> If I extend your example with an additional pointer and take the address of s
> it still doesn't allocate s in memory and as such cannot flush out the
> register content, which is perfectly legal. The pointer is completley
> eliminated (this is an extreme example).
>
> int sum(int a[], int l) {
> int i;
> int s = 0;
> int *sp = &s;
> for (i = 0; i < l; i++) {
> asm volatile("nop # Nothing at all":::"memory");
> *sp += a[i];
> }
> return s;
> }
But that's not reachable from the asm. Reachability is key here. The
address of s is taken, but not used; GCC knows that it is not
reachable.
>>> e.g. IMHO the last sentence of the paragraph already
>>> deals with this.
>>
>> Which last sentence of what paragraph?
>
> This one:
>
> | For performance reasons, some variables only exist in registers
> | and never get written to memory. The "memory" clobber does not
> | force these values to get written to memory.
Except when it does; this is why the technical language has to be
*precise*.
The memory clobber will force all reachable variables into memory: it
must.
If we're going to avoid precise technical terms like "reachable" we
have to find some other way of saying this, or not mention is at all.
We must not say things that are misleading.
Andrew.
doc bugs
Since we are nearing release, I thought I’d mention I see: ../../gcc/gcc/doc/invoke.texi:1114: warning: node next `Overall Options' in menu `C Dialect Options' and in sectioning `Invoking G++' differ ../../gcc/gcc/doc/invoke.texi:1114: warning: node up `Overall Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:1589: warning: node prev `C Dialect Options' in menu `Overall Options' and in sectioning `Invoking G++' differ ../../gcc/gcc/doc/invoke.texi:1589: warning: node up `C Dialect Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:2013: warning: node up `C++ Dialect Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:2835: warning: node up `Objective-C and Objective-C++ Dialect Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:3067: warning: node up `Language Independent Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:3193: warning: node up `Warning Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:5099: warning: node up `Debugging Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:6771: warning: node up `Optimize Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:10138: warning: node up `Preprocessor Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:10191: warning: node up `Assembler Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:10214: warning: node up `Link Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:10510: warning: node up `Directory Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:10664: warning: node up `Spec Files' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/invoke.texi:11241: warning: node up `Target Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ ../../gcc/gcc/doc/trouble.texi:5: warning: node next `Trouble' in menu `Service' and in sectioning `Bugs' differ ../../gcc/gcc/doc/trouble.texi:5: warning: node prev `Trouble' in menu `Bug Reporting' and in sectioning `Gcov' differ ../../gcc/gcc/doc/trouble.texi:5: warning: node up `Trouble' in menu `Bugs' and in sectioning `Top' differ ../../gcc/gcc/doc/service.texi:5: warning: node prev `Service' in menu `Trouble' and in sectioning `Bugs' differ ../../gcc/gcc/doc/service.texi:5: warning: node up `Service' in menu `Bugs' and in sectioning `Top’ differ I’ll just note this, not sure if it matters or if anyone cares…
Re: doc bugs
On Fri, Mar 28, 2014 at 12:41 PM, Mike Stump wrote: > Since we are nearing release, I thought I'd mention I see: > > ../../gcc/gcc/doc/invoke.texi:1114: warning: node next `Overall Options' in > menu `C Dialect Options' and in sectioning `Invoking G++' differ > ../../gcc/gcc/doc/invoke.texi:1114: warning: node up `Overall Options' in > menu `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:1589: warning: node prev `C Dialect Options' in > menu `Overall Options' and in sectioning `Invoking G++' differ > ../../gcc/gcc/doc/invoke.texi:1589: warning: node up `C Dialect Options' in > menu `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:2013: warning: node up `C++ Dialect Options' in > menu `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:2835: warning: node up `Objective-C and > Objective-C++ Dialect Options' in menu `Option Summary' and in sectioning > `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:3067: warning: node up `Language Independent > Options' in menu `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:3193: warning: node up `Warning Options' in > menu `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:5099: warning: node up `Debugging Options' in > menu `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:6771: warning: node up `Optimize Options' in > menu `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:10138: warning: node up `Preprocessor Options' > in menu `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:10191: warning: node up `Assembler Options' in > menu `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:10214: warning: node up `Link Options' in menu > `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:10510: warning: node up `Directory Options' in > menu `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:10664: warning: node up `Spec Files' in menu > `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/invoke.texi:11241: warning: node up `Target Options' in > menu `Option Summary' and in sectioning `Invoking GCC' differ > ../../gcc/gcc/doc/trouble.texi:5: warning: node next `Trouble' in menu > `Service' and in sectioning `Bugs' differ > ../../gcc/gcc/doc/trouble.texi:5: warning: node prev `Trouble' in menu `Bug > Reporting' and in sectioning `Gcov' differ > ../../gcc/gcc/doc/trouble.texi:5: warning: node up `Trouble' in menu `Bugs' > and in sectioning `Top' differ > ../../gcc/gcc/doc/service.texi:5: warning: node prev `Service' in menu > `Trouble' and in sectioning `Bugs' differ > ../../gcc/gcc/doc/service.texi:5: warning: node up `Service' in menu `Bugs' > and in sectioning `Top' > differ > > I'll just note this, not sure if it matters or if anyone cares... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59055 -- H.J.
Re: C Code in GCC Machine Descriptions
On Fri, Mar 28, 2014 at 8:48 AM, Saswat Padhi wrote:
>
> I am Saswat Padhi, a final year undergraduate at IIT Bombay, India.
> With help from the GCC Resource Center here, I am currently investing
> possible improvements to GCC Machine Descriptions, with a goal of
> making them concise and composable.
>
> One of the improvements we were looking at is, reducing the C code
> fragments within the define_expand constructs in the machine
> descriptions. In some of the define_expands we observed that the C
> code fragments implement the same checks which can equivalently be
> achieved through the use of constraints. So, we thought that
> introducing constraints-validation at the expander level could be
> useful. An example of change we are proposing, is illustrated below:
>
> (define_expand "movsi"
> [(set (match_operand:SI 0 "nonimmediate_operand" "")
> (match_operand:SI 1 "general_operand" "")
> )]
> ""
> { if(GET_CODE(operands[0])==MEM && GET_CODE(operands[1])!=REG)
> { if(can_create_pseudo_p())
> { operands[1]=force_reg(SImode,operands[1]); }
> }})
>
> With the expander handling the constraints, the above define_expand
> can be written as:
>
> (define_expand "movsi"
> [(set (match_operand:SI 0 "nonimmediate_operand" "=r,m,r,r")
> (match_operand:SI 1 "general_operand" "r,r,i,m")
> )]
> ""
> )
>
> This concise define_expand expression would achieve the desired effect
> because when the first operand matches the second constraint
> alternative [m], the second operand would be force_reg into the second
> alternative [r]. All other cases are also explicitly mentioned as
> alternative constraints.
>
> As a first step towards this, I prepared this report
> (https://docs.google.com/document/d/1Yb5b3-r4YfxEL0omvAqqGFGIYLLeMenn-EHQvSHgKUw/edit)
> which is a survey of the define_expand expressions in i386 and MIPS
> machine descriptions. But as the report explains, the results of the
> survey do not appear in our favor. We see very few define_expands
> where we can actually replace some parts of the C code by introducing
> constraint validation in the expander.
>
> I seek feedback from the community regarding:
> 1. Is the idea is worth pursuing? In other words, would we be able to
> reduce significant amount of C code from the GCC MDs by introducing
> constraint validation at expander?
>
> 2. If answer to (1) is yes, do the parameters mentioned in the report
> make sense? We use 3 parameters to estimate whether we would be able
> to simplify a define_expand by removing at least a part of the C code.
>
> 3. If the answer to (2) is yes, why don't we see any gain in i386 and
> MIPS MDs? Then are there other cases where the gain would be
> significant?
>
> Thank you in advance for your time and help :-)
Your result matches my intuition, which is that it wouldn't help much.
For simple cases where contraints can carry the load, a named pattern
can simply be a define_insn. For complex cases, constraints can not
carry the load. We are left with a bit of a middle-ground, where
constraints can help but there is still general work to be done in the
define_expand body. I don't think that middle ground is very large.
Ian
