Re: inline assembly
reed kotler writes: > For extended inline assembly, there are constraints. Some seem to be > supported by all architectures and some specific to a particular > architecture. > > Where are these defined in gcc source? > > Some seem to be in constraints.md and some not. Machine-specific constraints are normally defined in, as you say, config/CPU/constraints.md. The generic constraints are handled in a few different places, notably ira-*.c, reload.c and recog.c. Probably the easiest way to find them is to grep for REG_CLASS_FROM_CONSTRAINT and check the code around the places where that is used. Ian
gcc-4.6-20120224 is now available
Snapshot gcc-4.6-20120224 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120224/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 184564 You'll find: gcc-4.6-20120224.tar.bz2 Complete GCC MD5=ac06030bbc4a01b21c8769583c1a2571 SHA1=e123ddfae6cc586e9aef619e24dc70a50f2f7242 Diffs from 4.6-20120217 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
inline assembly
For extended inline assembly, there are constraints. Some seem to be supported by all architectures and some specific to a particular architecture. Where are these defined in gcc source? Some seem to be in constraints.md and some not. Tia. Reed
Re: Simulator testing for sh and sh64
Hi! On Thu, 23 Feb 2012 08:42:53 +0900, Kaz Kojima wrote: > Thomas Schwinge wrote: > > Kaz, is my understanding correct, that I simply use sh64-elf as target, > > and again the sh-sim board? Should I be setting a specific CPU when > > configuring GCC, or any other customization? > > I used sh64-sim board for sh64-elf. sh64-sim.exp baseboard can > be seen in > > http://lists.gnu.org/archive/html/dejagnu/2008-02/msg00056.html I gave both sh-sim and sh64-sim a try, and -- if I'm reading correctly between all the noise -- there isn't really much difference in the testresults depending on which of the two is being used. > > This means, for sh-elf sim testing, we have a bit too many failures in > > GCC and GDB, and some ld test harness issue. For sh64-elf we have a GCC > > trunk ICE, some section overlap issue, and even more GDB issues. > > Yep. About sh64, I had used sh64-linux as my testing target, but > unfortunately that real sh64 system stopped working after the earthquake. Ouch. :-/ Grüße, Thomas pgpkq7GpdnHMY.pgp Description: PGP signature
Proposal: Make TYPE_HASH != TYPE_UID
Over in the pph branch we are having several failures due to TYPE_CANONICAL and the canonical types table. Entries of the canonical types table corresponding to user-generated types get saved on each pre-parsed header. We then read the table back in and register the hash codes corresponding to each type. However, we later run into an ICE in comptypes() because the compiler gets different hash values from structurally identical types. The problem here is that the computation of type hash codes use a non-stable seed (TYPE_UID). When a header file is compiled independently to generate a corresponding pre-parsed header, types will receive different UIDs than when the file is compiled within a translation unit. Initially, I was toying with the idea of not saving the hash code but the steps needed to re-compute the hash code. This is not trivial, since all the hash code computations are open coded and do not always depend on the type itself (e.g., build_type_attribute_qual_variant). So, what I think will be more feasible to do is to make sure that types get stable hash codes that only depend on structural attributes of the type. So far, the only unstable element I've seen is the use of TYPE_UID in the hash computations. My proposal is to: 1- Separate TYPE_HASH from TYPE_UID. 2- Once a type T is entered in the canonical table, make TYPE_HASH(T) be the hash code that was used to enter the type. Another thing I noticed is that type_hash_canon insists that we only enter main variants of types. However, after being entered, some types get their TYPE_MAIN_VARIANT changed (this produces failures when we try to re-enter the types out of a PPH header, but this is simpler to resolve). Do you see any big problems with my plan? Thanks. Diego.
Re: Is it a bug when use “<<”if the operator is out of the size "0~63"
This question is not appropriate for this mailing list, questions about using GCC should be sent to the gcc-h...@gcc.gnu.org list, please take any follow up there, thanks. On 24 February 2012 08:34, Yang Yueming wrote: > > The result of xyz should be "0"，but it is "2468acf123579bc" ,same as xyz = > abc << 1,Why? The C standard says it's undefined behaviour: "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined."
Re: A question about redundant PHI expression stmt
On Fri, Feb 24, 2012 at 9:07 AM, Jiangning Liu wrote:
> Hi,
>
> For the small case below, there are some redundant PHI expression stmt
> generated, and finally cause back-end generates redundant copy instructions
> due to some reasons around IRA.
>
> int *l, *r, *g;
> void test_func(int n)
> {
> int i;
> static int j;
> static int pos, direction, direction_pre;
>
> pos = 0;
> direction = 1;
>
> for ( i = 0; i < n; i++ )
> {
> direction_pre = direction;
>
> for ( j = 0; j <= 400; j++ )
> {
>
> if ( g[pos] == 200 )
> break;
>
> if ( direction == 0 )
> pos = l[pos];
> else
> pos = r[pos];
>
> if ( pos == -1 )
> {
> if ( direction_pre != direction )
> break;
>
> pos = 0;
> direction = !direction;
> }
>
> }
>
> f(g[pos]);
> }
> }
>
> I know PR39976 has something to do with this case, and check-in r182140
> caused big degradation on the real benchmark, but I'm still confusing around
> this issue.
>
> The procedure is like this,
>
> Loop store motion generates code below,
>
> :
> D.4084_17 = l.4_13 + D.4077_70;
> pos.5_18 = *D.4084_17;
> pos_lsm.34_103 = pos.5_18;
> goto ;
>
> :
> D.4088_23 = r.6_19 + D.4077_70;
> pos.7_24 = *D.4088_23;
> pos_lsm.34_104 = pos.7_24;
>
> :
> # prephitmp.29_89 = PHI
> # pos_lsm.34_53 = PHI
> pos.2_25 = prephitmp.29_89;
> if (pos.2_25 == -1)
> goto ;
> else
> goto ;
>
> And then, copy propagation transforms block 8 it into
>
> :
> # prephitmp.29_89 = PHI
> # pos_lsm.34_53 = PHI
> ...
>
> And then, these two duplicated PHI stmts have been kept until expand pass.
>
> In dom2, a stmt like below
>
> # pos_lsm.34_54 = PHI
>
> is transformed into
>
> # pos_lsm.34_54 = PHI
>
> just because they are equal.
>
> Unfortunately, this transformation changed back-end behavior to generate
> redundant copy instructions and hurt performance. This case is from a real
> benchmark and hurt performance a lot.
>
> Does the fix in r182140 intend to totally clean up this kind of redundancy?
> Where should we get it fixed?
FRE/PRE are currently the only passes that remove redundant PHI nodes.
DOM can be trivially extended to do the same (I _think_ I had a patch for
this somewhere ... but in the end I think DOM should go, one VN is enough).
Richard.
> Thanks,
> -Jiangning
>
>
>
Re: Is it a bug when use “<<”if the operator is out of the size "0~63"
Yang Yueming writes: > long long abc = 0x01234567891abcde; > long long xyz; ... > xyz = abc << 65; ... > The result of xyz should be "0"，but it is "2468acf123579bc" ,same as > xyz = abc << 1,Why? Because the shift operators in C have an undefined result when the shift-count is larger than the size of the type. As the compiler generally just generates the underlying CPU's shift instruction, then what happens in practice depends on the CPU. Different CPUs do different things in such a case, and one popular alternative is to simply interpret the shift-count modulo the word-size. > So as for "int a<<35"and etc.. Same thing. -miles -- Electricity, n. The cause of all natural phenomena not known to be caused by something else.
Is it a bug when use “<<”if the operator is out of the size "0~63"
Case:
#include
#include
long long abc = 0x01234567891abcde;
long long xyz;
int main ()
{
xyz = abc << 65;
printf("%llx\n", xyz);
return 0;
}
The result of xyz should be "0"，but it is "2468acf123579bc" ,same as xyz = abc
<< 1,Why?
So as for "int a<<35"and etc..
YangYueming
A question about redundant PHI expression stmt
Hi,
For the small case below, there are some redundant PHI expression stmt
generated, and finally cause back-end generates redundant copy instructions
due to some reasons around IRA.
int *l, *r, *g;
void test_func(int n)
{
int i;
static int j;
static int pos, direction, direction_pre;
pos = 0;
direction = 1;
for ( i = 0; i < n; i++ )
{
direction_pre = direction;
for ( j = 0; j <= 400; j++ )
{
if ( g[pos] == 200 )
break;
if ( direction == 0 )
pos = l[pos];
else
pos = r[pos];
if ( pos == -1 )
{
if ( direction_pre != direction )
break;
pos = 0;
direction = !direction;
}
}
f(g[pos]);
}
}
I know PR39976 has something to do with this case, and check-in r182140
caused big degradation on the real benchmark, but I'm still confusing around
this issue.
The procedure is like this,
Loop store motion generates code below,
:
D.4084_17 = l.4_13 + D.4077_70;
pos.5_18 = *D.4084_17;
pos_lsm.34_103 = pos.5_18;
goto ;
:
D.4088_23 = r.6_19 + D.4077_70;
pos.7_24 = *D.4088_23;
pos_lsm.34_104 = pos.7_24;
:
# prephitmp.29_89 = PHI
# pos_lsm.34_53 = PHI
pos.2_25 = prephitmp.29_89;
if (pos.2_25 == -1)
goto ;
else
goto ;
And then, copy propagation transforms block 8 it into
:
# prephitmp.29_89 = PHI
# pos_lsm.34_53 = PHI
...
And then, these two duplicated PHI stmts have been kept until expand pass.
In dom2, a stmt like below
# pos_lsm.34_54 = PHI
is transformed into
# pos_lsm.34_54 = PHI
just because they are equal.
Unfortunately, this transformation changed back-end behavior to generate
redundant copy instructions and hurt performance. This case is from a real
benchmark and hurt performance a lot.
Does the fix in r182140 intend to totally clean up this kind of redundancy?
Where should we get it fixed?
Thanks,
-Jiangning
