Re: Generating DWARF CIE info

[Eric Botcazou]

> You set a breakpoint at the return address assuming that you
> will reach it when you finish the function.

OK, in this case you'll need to adjust like in the EH unwinder.

-- 
Eric Botcazou

[RFC] Aggregate mapping

[Jim Tison]

It was suggested that I post an RFC here. With advance apologies for its 
length, I am looking for comments, remarks, and/or advice.


I'm currently trying to code a C language structure for a complex block 
of 0x200 bytes in size from a paper document. This particular 
declaration is rife with bitfields, mis-aligned base datatypes, and 
reserved fields. What I need is to verify my coding against the paper 
document before I start testing code which uses it. I've looked through 
gcc documents and find nothing which fits this need: no obvious -d pass 
which would give me such a map, nor any other option or standalone 
program. I'm proposing to create a standalone program, as I don't know 
enough about gcc internals to force such maps to be generated during 
compilation ... I'm not certain this would be appropriate, anyway. OTOH, 
I can't be the first to propose solving this problem.


AFAICT, the only accurate source data for such an aggregate map would be 
DWARF DIE entries. This would mean that I'd be post-processing ELF 
objects generated with the -g switch. What I'd like to end up with is a 
program which is portable among ELF types and outputs accurate data when 
run on foreign CPU architectures; much like readelf attempts to. This 
means I'd need to generically handle Elf64 and Elf32 formats, as well as 
respect endianism. I'd like this program to be able to properly extract 
aggregate maps from the three basic ELF types: relocatable, absolute, 
and DSO.


I've done some reading of the DWARF-2 and DWARF-3 standards. What I see 
emitted as DWARF in gcc-4.1.x is marked as DWARF-2; but I'm told that 
gcc properly emits DWARF-3. Should I even check the version? Will I need 
to vary processing features by gcc level?


Since I'm targeting all three ELF object types, I'm thinking I have to 
start reading the sections .debug_info and .debug_abbrev at the DWARF CU 
level, and build a tree of CU-related data. I've actually started this 
bit of code and am somewhat happy with test results so far.


DWARF isn't exactly user-friendly for my purposes. I've built, read 
about, and attempted to grok libdwarf ... I have to confess that I don't 
quite get it; but I think I have a functional understanding of how DWARF 
data is laid out and related within gcc-emitted objects. Therefore, I'm 
planning to not use libdwarf except for its DW_* pp terms in libdwarf.h. 
I expect to hear that I should be using gcc/dwarf.h; but I'd need to be 
convinced that its enum type forms are versatile enough to use in decoding.


Nor am I planning to use libelf: it's too straightforward to find the 
ELF sections I need and to read the ELF header. Use of libelf seems too 
top-heavy, although elf.h is very valuable to me.


I don't know enough about Fortran, Ada, or Java to even be conversant in 
how these languages aggregate; if this program supports these languages, 
it will be accidentally. I'm starting with C language dialects 
(DW_LANG_C, DW_LANG_C89, DW_LANG_C99) and intend to add support for C++ 
once C function testing is complete -- C++ classes add complexity that I 
really don't want to deal with during initial development.


Here's the high-level functional design I've got so far:
 1. Read the ELF object file, determine its type, endianism, and 
bitness as written. Find the .shstrtab section, and point at the section 
headers. Through the section headers, find the .debug_info and 
.debug_abbrev sections. Read them into memory and make these copies 
persistent through the rest of this program's lifecycle.
 2. Index through the DWARF CU headers (in .debug_info) and determine a 
count of CUs.

 3. For each CU,
   (3a) Create an array of pointers into .debug_abbrev, reading the 
DW_TAGs as we go. For each DW_TAG_{structure_type, union_type}, mark the 
abbrev index item as "of interest".
   (3b) Iterate through .debug_info DIEs as delimited for the current 
CU, looking for abbreviation numbers we've marked as "of interest". For 
each interesting DIE,
   (3c) Preserve source filename/path of declaration, starting line 
number, aggregate type (struct/union), tag (if any), and total length. 
Now, work its child DIEs (members). For each:
   (3d) Report byte offset, byte length, bit offset, and bit length as 
available. [I don't particularly like the way bit offsets are reported 
within multi-byte bitfields, so I expect to do some division by 8 and 
adjust the byte offset as appropriate. If I can't fix this to the point 
where it makes sense for both endianisms, then I'll abandon this tweak.] 
Report the base type and identifier of the member.
   (3e) If there's a typedef associated with this aggregate type, 
identify its name and save it.
4. When all CUs have been extracted, display all extracted information 
about the aggregates and their members, appropriately grouped.


Where I've run into trouble so far is attempting to predict what kind of 
storage I'll need to save all this intermediate summary data. DWARF 
sections can get rather l

Re: machine learning for loop unrolling

[Grigori Fursin]

Hi,

In addition to Kenneth's reply, here are a few references you may want to look 
at:

Edwin Bonilla, "Predicting Good Compiler Transformations Using Machine 
Learning", 
MS Thesis, School of Informatics, University of Edinburgh, UK, October 2004. 
http://www.inf.ed.ac.uk/publications/thesis/online/IM040129.pdf
It's about using machine learning to predict loop unrolling.

F. Agakov, E. Bonilla, J. Cavazos, B. Franke, G. Fursin, M.F.P. O'Boyle, J. 
Thomson, 
M. Toussaint and C.K.I. Williams. Using Machine Learning to Focus Iterative 
Optimization. 
Proceedings of the 4th  Annual International Symposium on Code Generation and 
Optimization (CGO), 
New York, NY, USA, March 2006
http://fursin.net/papers/abcp2006.pdf

You may also want to look at our project on GCC Interactive Compilation 
Interface (GCC-ICI)
to access internal GCC transformations to enable external optimizations 
particularly
using machine learning (we are now working on a new version which should be 
available
in mid/end of summer):

http://gcc-ici.sourceforge.net
http://www.hipeac.net/system/files?file=7_Fursin.pdf

Hope it will be of any help,
Grigori Fursin

=
Grigori Fursin, PhD
Research Fellow, INRIA Futurs, France
http://fursin.net/research




Re: machine learning for loop unrolling
From: Kenneth Hoste  
To: stefan dot ciobaca+gcc at gmail dot com 
Cc: GCC  
Date: Fri, 8 Jun 2007 21:04:05 +0200 
Subject: Re: machine learning for loop unrolling 
References: <[EMAIL PROTECTED]> 



On 08 Jun 2007, at 16:31, Stefan Ciobaca wrote:


Hello everyone,

For my bachelor thesis I'm modifying gcc to use machine learning to
predict the optimal unroll factor for different loops (inspired from
this paper: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS- TR-938.pdf). 

Interesting. I'm using evolutionary algorithms for similar purposes in my 
current research...





Of course, not all of these are relevant to gcc. I'm looking at ways
to compute some of these features, hopefully the most relevant ones.
If there is already some work done that I could use in order to
compute some of these features, I'd be glad if you could tell me about
it. Also, if anyone can think of some useful features, related to the
target architecture or the loops structure, I'd be glad to hear about
them.


I'm afraid I can't help here, I'm not familiar at all with GCCs internals.


Also, I'm interested in some benchmarks. Many of the research papers
that describe compiler optimizations use the SPEC* benchmarks, but
these are not free, so I'm looking for alternatives. Currently I'm
looking into:


- OpenBench
- Botan
- CSiBE
- Polyhedron

(thanks to richi of #gcc for the last 3)

Do you know any other one that would be better? 

But I can help here. Polyhedron is Fortran-only, but are well-suited for timing 
experiments (i.e.
they run long enough to have reasonable running times, but aren't too long 
either).
CSiBE is more targetted to code size, I believe the runtimes are ridicously 
small. I'm not familiar
with the other two.
Some other possibilities:

* MiDataSets (also fairly small when run only once, but the suite allows you to 
adjust the outer
loop iteration count to increase runtimes) 
[http://sourceforge.net/projects/midatasets]
* MediaBench / MediaBench II: multimedia workloads, which typically iterate 
over frames for example
[http://euler.slu.edu/~fritts/ mediabench/]
* BioMetricsWorkload [http://www.ideal.ece.ufl.edu/main.php?action=bmw]
* BioPerf: gene sequence analysis, ... [http://www.bioperf.org/]
* some other benchmarks commonly used when testing GCC [http:// 
www.suse.de/~gcctest]

I've been using the above with GCC and most work pretty well (on x86).



Here is how I'm thinking of conducting the experiment:


- for each innermost loop:
  - compile with the loop unrolled 1x, 2x, 4x, 8x, 16x, 32x and
measure the time the benchmark takes
  - write down the loop features and the best unroll factor
- apply some machine learning technique to the above data to determine
the correlations between loop features and best unroll factor


Any idea which? There's a huge number of different techniques out there, 
choosing an appropiate one
is critical to success.


- integrate the result into gcc and measure the benchmarks again 

When using machine learning techniques to build some kind of model, a common 
technique is
crossvalidation.
Say you have 20 benchmarks, no matter which ones. You use the larger part of 
those (for example 15)
to build the model (i.e. determine the correlations between loop features and 
best unroll factor),
and then test performance of that on the other ones. The important thing is not 
to use the
benchmarks you test with when using the machine learning technique. That way, 
you can (hopefully)
show that the stuff you've learned should work for other programs too.


Do you think it is ok to only consider inner-most loops? Wh

Re: GCC 4.3.0 Status Report (2007-06-07)

[Mark Mitchell]

Andrew Pinski wrote:
> On 6/7/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> * PTR_PLUS branch.
>>
>>   I believe that this branch should be included in GCC 4.3.  Andrew,
>> would you please update me as to its status?

>> In particular, are there
>> any regressions on primary or secondary targets at this point?
> 
> Here is what is known about the branch on each of the primary/secondary
> targets:

Thanks for the status information.

Based on this, I do think that the branch is ready to merge.  Once the
dataflow merge is done, and things have had a day or two to settle,
please merge the PTR_PLUS branch.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

LTO Status Report (2007-06-10)

[Mark Mitchell]

Besides my duties as RM, I plan to focus my GCC development time on LTO.
 This project has been dormant for a while, due to a variety of
constraints, but we (my fellow Sourcerers and I) will be able to put
more effort into LTO in the near future.  Kenny plans to work on LTO
once dataflow is merged.  Google has resources available as well.  And,
hopefully, other volunteers will be interested as well.  So, I think
we're in position to kick off a more substantial effort to move this
from design to substantial proof of concept.

In particular, the goal that Kenny and I have in mind, after
consultation with David Edelsohn, is to get to the point where we can
build the C benchmarks in SPEC in LTO mode.

To kick things off, I've created some pages on the GCC Wiki that go into
more detail about concrete tasks required for LTO.  Start here:

  http://gcc.gnu.org/wiki/LinkTimeOptimization

and look for the "LTO Driver", "LTO Reader/Writer", and "LTO
Representation Changes" subpages.

There's something here for everyone:

1. Changes to the driver and collect2.
2. Definition of new DWARF attributes.
3. Reading and writing those DWARF attributes.
4. Eliminating hooks and other bits of global state.
5. Eliminating pre-GIMPLE generation/use of RTL.
6. Poking at the ELF symbol table to determine DECL_SECTION_NAME in the
LTO reader.

and more!

Although these Wiki pages are written in an authoritative form, I do not
mean to dicate anything.  It's just easier to write "X does Y" than "I
think X should do Y" everywhere.

That said, I think one of the ways in which I can be most useful is as
an architect and coordinator.  So, I would appreciate it if people who
wish to make substantive changes to the design sketch ask me about that
before changing the Wiki pages.  I would also appreciate if people would
keep me informed as to what they are working on, so that I can keep
track of what's happening, from a high level.  Certainly, CodeSourcery
will keep the community informed regarding what pieces we are tackling.
 (Since we're just now restarting the project, nobody has yet been
assigned concrete tasks.)

At present, I know that Daniel Berlin is currently moving the existing
LTO patches forward to a new branch based on the current mainline.
Daniel will let us know when the new branch is ready.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Miscompilations for cris-elf on dataflow-branch

[Hans-Peter Nilsson]

I hear dataflow-branch is near merge to trunk, so I thought it'd
be about time to verify that it works for the targets I
maintain...

Comparing dataflow-branch with trunk, both r125590, I see these
regressions (alas no improvements) on the branch for cris-elf
cross from x86_64-unknown-linux-gnu (Debian etch, I think):

gcc.sum gcc.c-torture/execute/20020201-1.c
gcc.sum gcc.c-torture/execute/20041011-1.c
gcc.sum gcc.c-torture/execute/920501-8.c
gcc.sum gcc.c-torture/execute/920726-1.c
gcc.sum gcc.c-torture/execute/ashldi-1.c
gcc.sum gcc.c-torture/execute/ashrdi-1.c
gcc.sum gcc.c-torture/execute/builtin-bitops-1.c
gcc.sum gcc.c-torture/execute/builtins/pr23484-chk.c
gcc.sum gcc.c-torture/execute/builtins/snprintf-chk.c
gcc.sum gcc.c-torture/execute/builtins/sprintf-chk.c

Though repeatable by anyone (see for example
), all
are unfortunately execution failures, so I thought best to do
some preliminary analysis.

Looking at the source code for what the tests have in common, it
seems all either use sprintf "%d" or a DImode shift operation
(requiring a library call).  My money is on all being the same
one bug.

Here's a cut-down test-case, derived from
gcc.c-torture/execute/builtin-bitops-1.c:

--
static int
my_popcountll (unsigned long long x)
{
  int i;
  int count = 0;
  for (i = 0; i < 8 * sizeof (unsigned long long); i++)
if (x & ((unsigned long long) 1 << i))
  count++;
  return count;
};

extern void abort (void);
extern void exit (int);

int
main (void)
{
  int i;
  
  if (64 != my_popcountll (0xULL))
abort ();;
  
  exit (0);
}
--

Here's the assembly diff to trunk, revisions as per above,
option -Os as mentioned below:

--- lshr1.s.trunk   2007-06-11 03:49:21.0 +0200
+++ lshr1.s.df  2007-06-11 03:49:59.0 +0200
@@ -15,7 +15,6 @@ _main:
move.d ___lshrdi3,$r2
moveq -1,$r10
 .L7:
-   move.d $r10,$r11
move.d $r0,$r12
Jsr $r2
btstq (1-1),$r10

To repeat this without building a complete toolchain, have a gcc
svn checkout with those darned mpfr and gmp available somewhere
(added in that checkout or installed on the host system), then
do, in an empty directory:
 /path/to/gcctop/configure --target=cris-elf --enable-languages=c && make 
all-gcc
This will give you a cc1, which you know how to handle. :)

To repeat with the program above named lshr1.c, just use:

 ./cc1 -Os lshr1.c

The lost insn, numbered 61 in both trees, loads the high part of
that all-bits operand to the register in which that part of the
parameter is passed to the DImode left-shift library function
__lshrdi3.  From the dump-file it seems the first pass it is
lost, is combine.

Let me know if I can be of help.

brgds, H-P

FW: [gnu.org #336636] Needed Java Compilers for SUSE Linux Enterprise Server 10

[Krupa Stephen Gadde]

Hi,

Can I get any help on this???

Thanks in advance

Regards,
Stephen K. Gadde

-Original Message-
From: Jeanne Rasata via RT [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 08, 2007 7:43 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [gnu.org #336636] Needed Java Compilers for SUSE Linux Enterprise
Server 10 

Hello, Stephen,

> [EMAIL PROTECTED] - Fri Jun 08 02:04:08 2007]: 
> I am Stephen from India, working for a company by name TATA ELXSI Ltd
> (www.tataelxsi.com  )
> I am trying to download Java Compilers for the new server that has SUSE
> Linux Enterprise Sever 10, I was re-directed to your site and I could not
> able to any link to download the same. I have a couple of questions that I
> would like to ask and they are as follows 
> 1. Do Java Compilers for my OS is free or do I need any license (Purchase
> the product license if they are not free)?
> 2. If they are free, where I get the link to download the same

I'm sorry, but as this is only a general contact address, I cannot
properly answer technical questions such as yours. The best I can do is
refer you to the GCC Manual (http://gcc.gnu.org/onlinedocs/ and
Frequently Asked Questions (http://gcc.gnu.org/faq.html). If neither of
those provide an answer to your question, please contact the GCC users'
help list; you can learn more about it at
(http://gcc.gnu.org/lists.html). I am sorry that I couldn't be of more help.
Sincerely,
-- 
Jeanne Rasata
Program Assistant
Free Software Foundation

---
Have we been helpful to you today?  Would you like to help
the FSF continue to spread the word about software freedom?
You too can become a member! Learn more at:
http://donate.fsf.org

Re: Miscompilations for cris-elf on dataflow-branch

[Seongbae Park (박성배, 朴成培)]

Thanks for the detailed instruction on how to reproduce it
- I have successfully reproduced the problem, and narrowed it down
to combine that's deleting the insn in question.
Hopefully I'll be able to figure out what's wrong soon.

Seongbae

On 6/10/07, Hans-Peter Nilsson <[EMAIL PROTECTED]> wrote:

I hear dataflow-branch is near merge to trunk, so I thought it'd
be about time to verify that it works for the targets I
maintain...

Comparing dataflow-branch with trunk, both r125590, I see these
regressions (alas no improvements) on the branch for cris-elf
cross from x86_64-unknown-linux-gnu (Debian etch, I think):

gcc.sum gcc.c-torture/execute/20020201-1.c
gcc.sum gcc.c-torture/execute/20041011-1.c
gcc.sum gcc.c-torture/execute/920501-8.c
gcc.sum gcc.c-torture/execute/920726-1.c
gcc.sum gcc.c-torture/execute/ashldi-1.c
gcc.sum gcc.c-torture/execute/ashrdi-1.c
gcc.sum gcc.c-torture/execute/builtin-bitops-1.c
gcc.sum gcc.c-torture/execute/builtins/pr23484-chk.c
gcc.sum gcc.c-torture/execute/builtins/snprintf-chk.c
gcc.sum gcc.c-torture/execute/builtins/sprintf-chk.c

Though repeatable by anyone (see for example
), all
are unfortunately execution failures, so I thought best to do
some preliminary analysis.

Looking at the source code for what the tests have in common, it
seems all either use sprintf "%d" or a DImode shift operation
(requiring a library call).  My money is on all being the same
one bug.

Here's a cut-down test-case, derived from
gcc.c-torture/execute/builtin-bitops-1.c:

--
static int
my_popcountll (unsigned long long x)
{
  int i;
  int count = 0;
  for (i = 0; i < 8 * sizeof (unsigned long long); i++)
if (x & ((unsigned long long) 1 << i))
  count++;
  return count;
};

extern void abort (void);
extern void exit (int);

int
main (void)
{
  int i;

  if (64 != my_popcountll (0xULL))
abort ();;

  exit (0);
}
--

Here's the assembly diff to trunk, revisions as per above,
option -Os as mentioned below:

--- lshr1.s.trunk   2007-06-11 03:49:21.0 +0200
+++ lshr1.s.df  2007-06-11 03:49:59.0 +0200
@@ -15,7 +15,6 @@ _main:
move.d ___lshrdi3,$r2
moveq -1,$r10
 .L7:
-   move.d $r10,$r11
move.d $r0,$r12
Jsr $r2
btstq (1-1),$r10

To repeat this without building a complete toolchain, have a gcc
svn checkout with those darned mpfr and gmp available somewhere
(added in that checkout or installed on the host system), then
do, in an empty directory:
 /path/to/gcctop/configure --target=cris-elf --enable-languages=c && make 
all-gcc
This will give you a cc1, which you know how to handle. :)

To repeat with the program above named lshr1.c, just use:

 ./cc1 -Os lshr1.c

The lost insn, numbered 61 in both trees, loads the high part of
that all-bits operand to the register in which that part of the
parameter is passed to the DImode left-shift library function
__lshrdi3.  From the dump-file it seems the first pass it is
lost, is combine.

Let me know if I can be of help.

brgds, H-P




--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";

Re: Miscompilations for cris-elf on dataflow-branch

[Seongbae Park (박성배, 朴成培)]

This little patch:

diff -r 9e2b1e62931a gcc/combine.c
--- a/gcc/combine.c Wed Jun 06 23:08:38 2007 +
+++ b/gcc/combine.c Mon Jun 11 05:39:25 2007 +
@@ -4237,7 +4237,7 @@ subst (rtx x, rtx from, rtx to, int in_d

 So force this insn not to match in this (rare) case.  */
  if (! in_dest && code == REG && REG_P (from)
-  && REGNO (x) == REGNO (from))
+  && reg_overlap_mentioned_p (x, from))
return gen_rtx_CLOBBER (GET_MODE (x), const0_rtx);

  /* If this is an object, we are done unless it is a MEM or LO_SUM, both

should fix the problem (thanks to Ian Lance Talyor and Andrew Pinski
for helping me debug the problem on IRC).
I've started the bootstrap/regtest on x86-64.
I'd appreciate it if you can test this on cris.
Although the change is approved by Ian already,
I think I'll hold the patch till the dataflow merge happens.
Thanks,

Seongbae

On 6/10/07, Seongbae Park (박성배, 朴成培) <[EMAIL PROTECTED]> wrote:

Thanks for the detailed instruction on how to reproduce it
- I have successfully reproduced the problem, and narrowed it down
to combine that's deleting the insn in question.
Hopefully I'll be able to figure out what's wrong soon.

Seongbae

On 6/10/07, Hans-Peter Nilsson <[EMAIL PROTECTED]> wrote:
> I hear dataflow-branch is near merge to trunk, so I thought it'd
> be about time to verify that it works for the targets I
> maintain...
>
> Comparing dataflow-branch with trunk, both r125590, I see these
> regressions (alas no improvements) on the branch for cris-elf
> cross from x86_64-unknown-linux-gnu (Debian etch, I think):
>
> gcc.sum gcc.c-torture/execute/20020201-1.c
> gcc.sum gcc.c-torture/execute/20041011-1.c
> gcc.sum gcc.c-torture/execute/920501-8.c
> gcc.sum gcc.c-torture/execute/920726-1.c
> gcc.sum gcc.c-torture/execute/ashldi-1.c
> gcc.sum gcc.c-torture/execute/ashrdi-1.c
> gcc.sum gcc.c-torture/execute/builtin-bitops-1.c
> gcc.sum gcc.c-torture/execute/builtins/pr23484-chk.c
> gcc.sum gcc.c-torture/execute/builtins/snprintf-chk.c
> gcc.sum gcc.c-torture/execute/builtins/sprintf-chk.c
>
> Though repeatable by anyone (see for example
> ), all
> are unfortunately execution failures, so I thought best to do
> some preliminary analysis.
>
> Looking at the source code for what the tests have in common, it
> seems all either use sprintf "%d" or a DImode shift operation
> (requiring a library call).  My money is on all being the same
> one bug.
>
> Here's a cut-down test-case, derived from
> gcc.c-torture/execute/builtin-bitops-1.c:
>
> --
> static int
> my_popcountll (unsigned long long x)
> {
>   int i;
>   int count = 0;
>   for (i = 0; i < 8 * sizeof (unsigned long long); i++)
> if (x & ((unsigned long long) 1 << i))
>   count++;
>   return count;
> };
>
> extern void abort (void);
> extern void exit (int);
>
> int
> main (void)
> {
>   int i;
>
>   if (64 != my_popcountll (0xULL))
> abort ();;
>
>   exit (0);
> }
> --
>
> Here's the assembly diff to trunk, revisions as per above,
> option -Os as mentioned below:
>
> --- lshr1.s.trunk   2007-06-11 03:49:21.0 +0200
> +++ lshr1.s.df  2007-06-11 03:49:59.0 +0200
> @@ -15,7 +15,6 @@ _main:
> move.d ___lshrdi3,$r2
> moveq -1,$r10
>  .L7:
> -   move.d $r10,$r11
> move.d $r0,$r12
> Jsr $r2
> btstq (1-1),$r10
>
> To repeat this without building a complete toolchain, have a gcc
> svn checkout with those darned mpfr and gmp available somewhere
> (added in that checkout or installed on the host system), then
> do, in an empty directory:
>  /path/to/gcctop/configure --target=cris-elf --enable-languages=c && make 
all-gcc
> This will give you a cc1, which you know how to handle. :)
>
> To repeat with the program above named lshr1.c, just use:
>
>  ./cc1 -Os lshr1.c
>
> The lost insn, numbered 61 in both trees, loads the high part of
> that all-bits operand to the register in which that part of the
> parameter is passed to the DImode left-shift library function
> __lshrdi3.  From the dump-file it seems the first pass it is
> lost, is combine.
>
> Let me know if I can be of help.
>
> brgds, H-P
>


--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";




--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";