Subversion Repositories Open64

[/] [trunk/] [osprey/] [be/] [cg/] [op.h] - Rev 2694

Rev

Go to most recent revision | Details | Compare with Previous | Blame

Filtering Options

Clear current filter

Rev Log message Author Age Path
2694 merge open-sl branch change(r2110:2693) to trunk shenruifen 1268d 07h /trunk/osprey/be/cg/op.h
2670 Just use "dos2unix" to format osprey/be/cg/op.h shenruifen 1287d 09h /trunk/osprey/be/cg/op.h
2111 merge open-sl branch change(r2035:r2110) to trunk shenruifen 1538d 14h /trunk/osprey/be/cg/op.h
1950 Merge branches/merge08 into trunk.
Now the trunk is the latest revision for Open64 4.2 release.
The trunk now can generate code for 5 platforms:
- IA-32/x86_64
- IA-64 (Itanium)
- CUDA (from NVIDIA)
- SL (an embedded DSP architecture, from SimpLight)
- MIPS prototype (from ICT based on input from PathScale and SimpLight
The trunk is merged with PathScale 3.2 release with a lot of enhancement and
bug fix from Tsinghua Univ., NVIDIA, SimpLight, HP and ICT.
laijx 1698d 01h /trunk/osprey/be/cg/op.h
1446 Fixed the overlaped FLAG defintion for OP. hucheng 1909d 08h /trunk/osprey/be/cg/op.h
1411 Replace all files in trunk with the merge branch.
Now the files in trunk should be the same as in the merge branch
laijx 1945d 06h /trunk/osprey/be/cg/op.h
1107 This tiny change is about ltoffx+ldxmov/ld8.mov relocation support. The code sequence of global data will become :
addl r2=@ltoffx(dataname#),gp,
ld8.mov r2=[r2], dataname# // HP cc use ldxmov instead
ld1 r3=[r2];
Linker will change the ld8.mov into 'mov' if the load from GOT turns out to be unnecessary. To the best of my knowledge, this reloc support is dedicatd to ia64. Since it acutally does not entails HW support, I guess similar tech/trick are availale for other arch.

This change is super-trival. I associate the OP loading address from GOT with the corresponding symbol, the code-emit is intercerpted so that the ld8.mov can be emitted properly. Some small benchmarks as well as CPU2k are tested. Crafty obtains 3-4% improvement (I am sure it is genuine). Others remain unchanged (or I am not sure).
syang 2166d 17h /trunk/osprey/be/cg/op.h
1047 Rename kpro64 to osprey. The makefile will not work in several hours laijx 2183d 01h /trunk/osprey/be/cg/op.h
956 transfter 832 833 834 835 928 from open3.1 to new trunk, these are shuxin's implict call operand's fix, this transfer
fix the running time error for 176.gcc at -O2 -gnu4(it's a problem when return value's register r8 is reallocated by lra). it's only related to ia64, I had enclosed them by ifdef. also test it on x8664 for spec2kint at -O2.
tianwei 2213d 08h /trunk/osprey/be/cg/op.h
926 The 'merge' branch is now our new trunk. ributzka 2233d 21h /trunk/osprey/be/cg/op.h
901 move r883 and 886 from trunk syang 2239d 22h /trunk/osprey/be/cg/op.h
893 transfer the trunk 851 into branches tianwei 2241d 12h /trunk/osprey/be/cg/op.h
749 Check in the CG, include ~/be/be, ~/be/cg/;
Check in the instrumentation merge;
Check in the merge of directry ~/kpro64/common/*;
Some modify of ipa.
Just test on IA-64, when build it on X8664,
please NOTE add "-DCG_PATHSCALE_MERGE" in ~/Makefile.gsetup.
Moreover, there must be bugs, I still check in it since other stuffs can do work parallelly.
hucheng 2298d 06h /trunk/osprey/be/cg/op.h
722 Create new branch 'merge' from trunk ributzka 2304d 15h /trunk/osprey/be/cg/op.h
594 This is the first step of reorganizing the repository (and many will
follow).

The new repository will have the following main structure:
* branches
Branches of Open64, like Open64-2.0, will be put here
* trunk
Here is our development code.
* tags
Final releases, like Open64-2.0, Open64-2.0.1, etc, will be put here
* legacy
ributzka 2428d 17h /trunk/osprey/be/cg/op.h
583 1) workaround for CGIR implicit use/def problem -- see the comments to the functions. 2) fix to 154 syang 2440d 12h /trunk/osprey/be/cg/op.h
568 these fixes are done by jianxin and lixin:
1. bug no. 87
Open64 compiler couldn't identify the branch registers in inline asm statements
like "b6" in "asm("" : : : "cc", "b6" )" properly. The objective of this fix is
to make the compiler recognizing this kind of registers.

2.bug no. 88
Certain types of asm statements could cause assertion failure during global code
motion phase in original Open64 compiler. This problem is due to the compiler back-end
marking wrong arcs as candidates for data speculation in dependence graph.
Actually, They are not. The objective of this fix is to eliminate this kind inconsistency
in the compiler.

3. bug no.90
he bug occurred in Pre_Optimizer using native compiler. The same error
may not happen in cross compiler.
tianwei 2457d 00h /trunk/osprey/be/cg/op.h
505 When judging whether an instruction is spill/resore, the compiler mainly depends on whether the relative TN's spill field is NULL. This is not trustable when some optimization is performed, propagation for example.
The bug can be fixed by adding an flag to the struct op to tell which op is the
true spill/restore operation.
tianwei 2529d 15h /trunk/osprey/be/cg/op.h
179 source borrow from open64-1.0 syang 2708d 18h /trunk/osprey/be/cg/op.h