Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-05-02 Thread Maciej W. Rozycki 
On Tue, 26 Apr 2016, Jeff Law wrote:

> > So offhand I think you need an RTL instruction splitter to express this,
> > and then avoid fetching 64 bits worth of data from memory -- for the sake
> > of matching the indexed addressing mode -- where you only need 32 bits.
> > At the hardware instruction level I'd use a scratch register (as with
> > MOVAQ you'd have to waste one anyway) to scale the index and then use
> > MOVAL instead with the modified index.  Where no index is used it gets
> > simpler even as you can just bump up the displacement according to the
> > subreg offset.
> Note you shouldn't need an expander for this.
> 
> That insn is just a 32bit load.  I would have expected something to simplify
> the subreg expression, likely requiring loading the address into a register in
> the process.

 Hmm, producing a MOVAQ/MOVL sequence (rather than fiddling with the index 
register) will ensure any increment/decrement mode works just fine.  This 
observation also makes me agree with you in that we should always just 
load the result of the original address expression somewhere; likely a 
register, but on a VAX it could well be memory (though the indirect 
address mode is not offsettable; not in the sense perhaps needed here), so 
maybe we don't have to restrict that.

  Maciej

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-04-26 Thread Jeff Law 

On 04/01/2016 01:06 PM, Jake Hamby wrote:


My theory is that it has to do with liveness detection and a write
into the stack frame being incorrectly seen as updating a local
variable, but that could be completely wrong. I was hoping that by
cc'ing gcc-patches that somebody more familiar with why some phase of
the optimizer might decide to delete this particular insn that copies
data into the stack (to overwrite the return address, e.g. to move to
EH_RETURN_HANDLER_RTX) immediately before returning.
Dead store elimination is the most likely candidate.  It "knows" that 
stores into the local frame are dead when the function returns and uses 
that information to eliminate such stores.


You may just need to set the volatile flag on the MEM when you generate 
it in your backend.  For example see 
config/pa/pa.c::pa_eh_return_handler_rtx.


Jeff

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-04-26 Thread Jeff Law 

On 03/31/2016 02:29 PM, Jake Hamby wrote:


The failures all seem to be related to trying to read a value from an
array of 64-bit values and loading it into a 32-bit register. It
seems like there should be a special insn defined for this sort of
array access, since VAX has mova* and pusha* variants to set a value
from an address plus an index into a byte, word, long, or 64-bit
array (it uses movab/pushab, put not the other variants). The
addressing modes, constraints, and predicates all get very
complicated, and I still need to understand a bit better what is
actually required, and what could be simplified and cleaned up.

If anyone has suggestions on how to define an instruction that would
solve the previous failure, please let me know. Even without a
special pattern for the "(plus:SI (mult:SI (reg:SI) (const_int 8)))",
it should be able to generate something. It seems like it's expanding
something and then the insn that's supposed to go with it isn't
matching.

I tried adding define_insns for "movstrictsi" and for "truncdisi2",
hoping that one of them would solve the "(set (reg:SI (subreg:SI
(mem:DI (...)" part of the situation, but it didn't help. The
"(subreg:SI)" stuff is strange, and I don't understand exactly what
GCC is expecting the backend to define. I'll keep working on things
and as soon as I have something that I think is in a contributable
state and doesn't generate bad code, I'll email it.

subregs have two meanings depending on how they're used.

If the mode of the subreg is wider than the mode of the inner object, 
then it's what we often call a paradoxical subreg.  Essentially we're 
referring to the inner object in a wider mode with the additional bits 
all having undefined values.


subregs may also be used when referring to parts of an object.  In this 
case the subreg refers to a 32bit hunk of a 64bit memory object.


I suspect something should have simplified that particular subreg before 
it got into the IL and the compiler tried to recognize it.


I would suggest extracting a .i/.ii file which shows this problem and 
the necessary flags and reporting it as a bug.



jeff

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-04-26 Thread Jeff Law 

On 04/01/2016 05:37 AM, Bernd Schmidt wrote:

Cc'ing Matt Thomas who is listed as the vax maintainer; most of the
patch should be reviewed by him IMO. If he is no longer active I'd
frankly rather deprecate the port rather than invest effort in keeping
it running.


Index: gcc/except.c
===
RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/except.c,v
retrieving revision 1.3
diff -u -r1.3 except.c
--- gcc/except.c23 Mar 2016 15:51:36 -1.3
+++ gcc/except.c28 Mar 2016 23:24:40 -
@@ -2288,7 +2288,8 @@
  #endif
  {
  #ifdef EH_RETURN_HANDLER_RTX
-  emit_move_insn (EH_RETURN_HANDLER_RTX, crtl->eh.ehr_handler);
+  rtx insn = emit_move_insn (EH_RETURN_HANDLER_RTX,
crtl->eh.ehr_handler);
+  RTX_FRAME_RELATED_P (insn) = 1;// XXX FIXME in VAX backend?
  #else
error ("__builtin_eh_return not supported on this target");
  #endif


This part looks highly suspicious and I think there needs to be further
analysis.

Agreed 100%.  This is a symptom of a problem elsewhere.

jeff

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-04-26 Thread Jeff Law 

On 04/04/2016 08:51 AM, Maciej W. Rozycki wrote:

On Thu, 31 Mar 2016, Jake Hamby wrote:


There's one more thing that's broken in the VAX backend which I'd
*really* like to fix: GCC can't compile many of its own files at -O2, as
well as a few other .c files in the NetBSD tree, because it can't expand
an insn pattern. The Makefiles have hacks to add "-O0" on VAX, and when
I remove that workaround, I get GCC assertion failures, all of the form:

/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c: In function 
'void maybe_emit_chk_warning(tree, built_in_function)':
/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c:11549:1: error: 
unrecognizable insn:
 }
 ^
(insn 295 294 296 25 (set (reg:SI 111)
(subreg:SI (mem:DI (plus:SI (mult:SI (reg:SI 109)
(const_int 8 [0x8]))
(reg/f:SI 45 [ D.85015 ])) [7 *_98+0 S8 A32]) 4)) 
/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/wide-int.h:799 -1
 (nil))
/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c:11549:1: 
internal compiler error: in extract_insn, at recog.c:2343
0xbd0365 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/rtl-error.c:110
0xbd03fa _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/rtl-error.c:118
0xb92a2d extract_insn(rtx_insn*)

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/recog.c:2343
0x9612cd instantiate_virtual_regs_in_insn

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:1598
0x9612cd instantiate_virtual_regs

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:1966
0x9612cd execute

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:2015

The failures all seem to be related to trying to read a value from an
array of 64-bit values and loading it into a 32-bit register. It seems
like there should be a special insn defined for this sort of array
access, since VAX has mova* and pusha* variants to set a value from an
address plus an index into a byte, word, long, or 64-bit array (it uses
movab/pushab, put not the other variants). The addressing modes,
constraints, and predicates all get very complicated, and I still need
to understand a bit better what is actually required, and what could be
simplified and cleaned up.


 Please note however that this RTL instruction is a memory reference, not
an address load.  So the suitable hardware instruction would be MOVAQ for
an indexed DI mode memory load.  If used to set a SI mode subreg at byte
number 4 (this would be the second hardware register of a pair a DI mode
value is held in) as seen here, it would have to address the immediately
preceding register however (so you can't load R0 this way) and it would
clobber it.

 So offhand I think you need an RTL instruction splitter to express this,
and then avoid fetching 64 bits worth of data from memory -- for the sake
of matching the indexed addressing mode -- where you only need 32 bits.
At the hardware instruction level I'd use a scratch register (as with
MOVAQ you'd have to waste one anyway) to scale the index and then use
MOVAL instead with the modified index.  Where no index is used it gets
simpler even as you can just bump up the displacement according to the
subreg offset.

Note you shouldn't need an expander for this.

That insn is just a 32bit load.  I would have expected something to 
simplify the subreg expression, likely requiring loading the address 
into a register in the process.


Jeff

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-04-09 Thread Maciej W. Rozycki 
On Fri, 8 Apr 2016, Jake Hamby wrote:

> Thanks for the info! I've discovered a few additional clues which should 
> help, namely the optimizer pass that's introducing the problem. Through 
> process of elimination, I discovered that adding "-fno-tree-ter" will 
> prevent the unrecognizable insn error. Strangely, I can't cause the 
> problem by using "-ftree-ter" and -O0, which seems odd, unless the code 
> is checking directly for a -O flag.

 You can't turn most optimisations on at -O0, you need to globally enable 
optimisation in the first place -- any -O setting will do, e.g. -O, -Os, 
etc., as per the GCC manual:

"Most optimizations are only enabled if an `-O' level is set on the
command line.  Otherwise they are disabled, even if individual
optimization flags are specified."

So to enable a single optimisation only you'll have to use e.g. -O 
combined with a list of negated -f options to disable this level's 
optimisation defaults.  Yes, I agree this sounds like an awkward UI; I 
guess it dates back to GCC's early days and nobody bothered to fix it.  
Maybe we need -Onone or suchlike.

> I'll continue to clean up the diffs that I've been working on, and send 
> out something when I've made more progress. I like the "cc" attr code 
> that I've added to fix the overaggressive elimination of CC0 tests, but 
> the problem is that now it's too conservative, because many insns are 
> defined as calls into C code which may or may not generate insns that 
> set the condition codes. I have a few ideas on how to clean up and 
> refactor that code, but first I had to convince myself that most of 
> what's in there now are actually useful optimizations, and they seem to 
> be.

 Good luck!

> Thanks for the help!

 You are welcome!

  Maciej

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-04-08 Thread Jake Hamby 

> On Apr 4, 2016, at 07:51, Maciej W. Rozycki  wrote:
> 
> On Thu, 31 Mar 2016, Jake Hamby wrote:
> 
>> There's one more thing that's broken in the VAX backend which I'd 
>> *really* like to fix: GCC can't compile many of its own files at -O2, as 
>> well as a few other .c files in the NetBSD tree, because it can't expand 
>> an insn pattern. The Makefiles have hacks to add "-O0" on VAX, and when 
>> I remove that workaround, I get GCC assertion failures, all of the form:
>> 
>> /home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c: In function 
>> 'void maybe_emit_chk_warning(tree, built_in_function)':
>> /home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c:11549:1: 
>> error: unrecognizable insn:
>> }
>> ^
>> (insn 295 294 296 25 (set (reg:SI 111)
>>(subreg:SI (mem:DI (plus:SI (mult:SI (reg:SI 109)
>>(const_int 8 [0x8]))
>>(reg/f:SI 45 [ D.85015 ])) [7 *_98+0 S8 A32]) 4)) 
>> /home/netbsd/current/src/external/gpl3/gcc/dist/gcc/wide-int.h:799 -1
>> (nil))
>> /home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c:11549:1: 
>> internal compiler error: in extract_insn, at recog.c:2343
>> 0xbd0365 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
>> const*)
>>  
>> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/rtl-error.c:110
>> 0xbd03fa _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>>  
>> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/rtl-error.c:118
>> 0xb92a2d extract_insn(rtx_insn*)
>>  
>> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/recog.c:2343
>> 0x9612cd instantiate_virtual_regs_in_insn
>>  
>> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:1598
>> 0x9612cd instantiate_virtual_regs
>>  
>> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:1966
>> 0x9612cd execute
>>  
>> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:2015
>> 
>> The failures all seem to be related to trying to read a value from an 
>> array of 64-bit values and loading it into a 32-bit register. It seems 
>> like there should be a special insn defined for this sort of array 
>> access, since VAX has mova* and pusha* variants to set a value from an 
>> address plus an index into a byte, word, long, or 64-bit array (it uses 
>> movab/pushab, put not the other variants). The addressing modes, 
>> constraints, and predicates all get very complicated, and I still need 
>> to understand a bit better what is actually required, and what could be 
>> simplified and cleaned up.
> 
> Please note however that this RTL instruction is a memory reference, not 
> an address load.  So the suitable hardware instruction would be MOVAQ for 
> an indexed DI mode memory load.  If used to set a SI mode subreg at byte 
> number 4 (this would be the second hardware register of a pair a DI mode 
> value is held in) as seen here, it would have to address the immediately 
> preceding register however (so you can't load R0 this way) and it would 
> clobber it.
> 
> So offhand I think you need an RTL instruction splitter to express this, 
> and then avoid fetching 64 bits worth of data from memory -- for the sake 
> of matching the indexed addressing mode -- where you only need 32 bits.  
> At the hardware instruction level I'd use a scratch register (as with 
> MOVAQ you'd have to waste one anyway) to scale the index and then use 
> MOVAL instead with the modified index.  Where no index is used it gets 
> simpler even as you can just bump up the displacement according to the 
> subreg offset.

Thanks for the info! I've discovered a few additional clues which should help, 
namely the optimizer pass that's introducing the problem. Through process of 
elimination, I discovered that adding "-fno-tree-ter" will prevent the 
unrecognizable insn error. Strangely, I can't cause the problem by using 
"-ftree-ter" and -O0, which seems odd, unless the code is checking directly for 
a -O flag.

Here's an example of a similar line of code (it seems to be triggered by 
accessing a 64-bit int array embedded inside a struct) that fails w/ -O, but 
succeeded with the addition of -fno-tree-ter (assembly output with "-dP"):

#(insn 682 680 686 (set (reg:DI 0 %r0 [orig:136 D.5219 ] [136])
#(mem:DI (plus:SI (plus:SI (mult:SI (reg/v:SI 11 %r11 [orig:138 j ] 
[138])
#(const_int 8 [0x8]))
#(reg/v/f:SI 6 %r6 [orig:55 dp ] [55]))
#(const_int 112 [0x70])) [5 MEM[base: dp_3, index: _569, step: 
8, offset: 112B]+0 S8 A32])) /home/netbsd/current/src/sbin/fsck_ffs/pass1.c:345 
11 {movdi}
# (expr_list:REG_EQUIV (mem:DI (plus:SI (plus:SI (mult:SI (reg/v:SI 11 %r11 
[orig:138 j ] [138])
#(const_int 8 [0x8]))
#(reg/v/f:SI 6 %r6 [orig:55 dp ] [55]))
#

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-04-04 Thread Maciej W. Rozycki 
On Thu, 31 Mar 2016, Jake Hamby wrote:

> There's one more thing that's broken in the VAX backend which I'd 
> *really* like to fix: GCC can't compile many of its own files at -O2, as 
> well as a few other .c files in the NetBSD tree, because it can't expand 
> an insn pattern. The Makefiles have hacks to add "-O0" on VAX, and when 
> I remove that workaround, I get GCC assertion failures, all of the form:
> 
> /home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c: In function 
> 'void maybe_emit_chk_warning(tree, built_in_function)':
> /home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c:11549:1: 
> error: unrecognizable insn:
>  }
>  ^
> (insn 295 294 296 25 (set (reg:SI 111)
> (subreg:SI (mem:DI (plus:SI (mult:SI (reg:SI 109)
> (const_int 8 [0x8]))
> (reg/f:SI 45 [ D.85015 ])) [7 *_98+0 S8 A32]) 4)) 
> /home/netbsd/current/src/external/gpl3/gcc/dist/gcc/wide-int.h:799 -1
>  (nil))
> /home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c:11549:1: 
> internal compiler error: in extract_insn, at recog.c:2343
> 0xbd0365 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
> const*)
>   
> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/rtl-error.c:110
> 0xbd03fa _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>   
> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/rtl-error.c:118
> 0xb92a2d extract_insn(rtx_insn*)
>   
> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/recog.c:2343
> 0x9612cd instantiate_virtual_regs_in_insn
>   
> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:1598
> 0x9612cd instantiate_virtual_regs
>   
> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:1966
> 0x9612cd execute
>   
> /home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:2015
> 
> The failures all seem to be related to trying to read a value from an 
> array of 64-bit values and loading it into a 32-bit register. It seems 
> like there should be a special insn defined for this sort of array 
> access, since VAX has mova* and pusha* variants to set a value from an 
> address plus an index into a byte, word, long, or 64-bit array (it uses 
> movab/pushab, put not the other variants). The addressing modes, 
> constraints, and predicates all get very complicated, and I still need 
> to understand a bit better what is actually required, and what could be 
> simplified and cleaned up.

 Please note however that this RTL instruction is a memory reference, not 
an address load.  So the suitable hardware instruction would be MOVAQ for 
an indexed DI mode memory load.  If used to set a SI mode subreg at byte 
number 4 (this would be the second hardware register of a pair a DI mode 
value is held in) as seen here, it would have to address the immediately 
preceding register however (so you can't load R0 this way) and it would 
clobber it.

 So offhand I think you need an RTL instruction splitter to express this, 
and then avoid fetching 64 bits worth of data from memory -- for the sake 
of matching the indexed addressing mode -- where you only need 32 bits.  
At the hardware instruction level I'd use a scratch register (as with 
MOVAQ you'd have to waste one anyway) to scale the index and then use 
MOVAL instead with the modified index.  Where no index is used it gets 
simpler even as you can just bump up the displacement according to the 
subreg offset.

 HTH,

  Maciej

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-04-04 Thread Jan-Benedict Glaw 
On Fri, 2016-04-01 12:06:20 -0700, Jake Hamby  wrote:
> I apologize for the poor quality of the initial version of the patch
> that I submitted. I think I may have also mangled it by not

Don't apologize!  Posting work early enables others to comment on it.
GCC is a highly complex beast; nobody will produce a perfectly looking
patch on their first try.

[...]

> To be honest, my hope by sending out my work now, even in such a
> rough state, would be to try to avoid deprecating the GCC port to
> VAX, if only because: 1) there doesn't seem to be a compelling
> reason to remove support for it since it doesn't use any really old
> code paths that aren't also used by other backends (e.g. m68k and
> Atmel AVR use cc0, IBM S/390 uses non-IEEE FP formats), so it
> doesn't seem to be preventing any optimizations or code refactoring
> elsewhere in GCC that I could see, 2) even though NetBSD could
> continue to support VAX GCC, I noticed in the ChangeLogs that
> whenever somebody has made a change to a definition that affects the
> backends, they're usually very good about updating all of the
> backends so that they continue to compile, at least. So leaving the
> VAX backend in the tree would be beneficial from a maintenance
> standpoint for users of it, 3) the VAX backend is perhaps somewhat
> useful as a test case for GCC because so many unusual RTX standard
> instructions were obviously defined *for* it (although x86 defines a
> lot of them, too), although my interest is personally in preserving
> an interesting piece of computer history, and for nostalgia
> purposes.

As of now, ther VAX backend isn't near deprecation IMO. There'a
maintainer (Matt), who did quite a revamp a few years ago bringing the
VAX backend quite forward.  I also quite care for that backend and the
Build Robot I'm running is primarily(!) running to detect VAX
breakages early. (In fact, quite often Matt and I communicate over
submitted patches to the VAX backend.)

> I sent an earlier email to port-vax suggesting that future
> discussions of this project aren't relevant to gcc-patches, but I
> did want to get it on a few people's radar on the NetBSD side and
> try to solicit a bit of help on the questions I had as to how to
> avoid having to add that hack to gcc/except.c to make the optimizer
> not delete the insns. All of the other stuff can be worked on in
> NetBSD-current and avoid bothering the 99% of people who subscribe
> to gcc-patches who have no interest in the VAX backend.

You should /for sure/ bother the gcc-patches people! Please keep
Cc'ing patches to that mailing list.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  [Nach Firefox-Update gibt es Empfehlungen, wenn man einen 
neuen Tab aufmacht.]
the second  :   13:26 <@jbglaw> "Hide the new 
tab page"
13:27 <@jbglaw> Warum zum Teufel sind gerade Kacheln so 
ungeheuer angesagt?!
  13:57 <@andrel> die Mozilla Foundation hat eine LKW Ladung 
Fugenkitt gespendet bekommen?


signature.asc
Description: Digital signature

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-04-01 Thread Jake Hamby 
Hi,

I apologize for the poor quality of the initial version of the patch that I 
submitted. I think I may have also mangled it by not disabling the "smart 
quotes" feature on my Mac before I pasted in the diff from the terminal window. 
I intentionally did not use gmail for fear of adding word wraps or converting 
tabs to spaces, but apparently I mangled the patch anyway. I emailed Christos a 
.tar.gz version separately.

Yes, the file you highlighted is definitely not correct and I need to figure 
out how to fix it properly. For some reason the optimizer is deleting the 
emit_move_insn() on VAX, while it seems to work on all the other platforms that 
define EH_RETURN_HANDLER_RTX() and depend on that instruction. So I'm looking 
into fixing it in gcc/config/vax/something. My next step to try to figure out 
what's going on is to dump the trees for all the phases when building 
unwind-dw2.o (the only file where __builtin_eh_return() has to work in GCC when 
libgcc is compiled in order for C++ exceptions to work) with and without "-O", 
and figure out when the instruction is being deleted and why. This only affects 
functions that call __builtin_eh_return() instead of return, but I think 
cc1plus may also need it to be defined correctly for some code that it 
generates.

My theory is that it has to do with liveness detection and a write into the 
stack frame being incorrectly seen as updating a local variable, but that could 
be completely wrong. I was hoping that by cc'ing gcc-patches that somebody more 
familiar with why some phase of the optimizer might decide to delete this 
particular insn that copies data into the stack (to overwrite the return 
address, e.g. to move to EH_RETURN_HANDLER_RTX) immediately before returning.

So far I haven't found any actual bugs in GCC that should be fixed. Perhaps it 
isn't correct to check in a hack like the change to gcc/except.c into 
netbsd-current except temporarily, until there's a correct fix for that part of 
the issue, which is what I'd like to figure out. In the meantime, I would 
highly recommend adding an #ifdef __vax around that line to avoid trouble with 
the other ports.

Now that I think about it, please do not check in the patch to 
gcc/dist/gcc/except.c without an #ifdef __vax, and certainly this isn't ready 
to go into GCC mainline. But I think it will be ready with a few more 
adjustments. The important thing is that I think most, if not all of the 
necessary fixes will be entirely modifications to VAX-related files that can be 
locally patched in NetBSD regardless of whether the GCC maintainers accept them 
or not.

To be honest, my hope by sending out my work now, even in such a rough state, 
would be to try to avoid deprecating the GCC port to VAX, if only because: 1) 
there doesn't seem to be a compelling reason to remove support for it since it 
doesn't use any really old code paths that aren't also used by other backends 
(e.g. m68k and Atmel AVR use cc0, IBM S/390 uses non-IEEE FP formats), so it 
doesn't seem to be preventing any optimizations or code refactoring elsewhere 
in GCC that I could see, 2) even though NetBSD could continue to support VAX 
GCC, I noticed in the ChangeLogs that whenever somebody has made a change to a 
definition that affects the backends, they're usually very good about updating 
all of the backends so that they continue to compile, at least. So leaving the 
VAX backend in the tree would be beneficial from a maintenance standpoint for 
users of it, 3) the VAX backend is perhaps somewhat useful as a test case for 
GCC because so many unusual RTX standard instructions were obviously defined 
*for* it (although x86 defines a lot of them, too), although my interest is 
personally in preserving an interesting piece of computer history, and for 
nostalgia purposes.

I sent an earlier email to port-vax suggesting that future discussions of this 
project aren't relevant to gcc-patches, but I did want to get it on a few 
people's radar on the NetBSD side and try to solicit a bit of help on the 
questions I had as to how to avoid having to add that hack to gcc/except.c to 
make the optimizer not delete the insns. All of the other stuff can be worked 
on in NetBSD-current and avoid bothering the 99% of people who subscribe to 
gcc-patches who have no interest in the VAX backend.

Best regards,
Jake


> On Apr 1, 2016, at 04:37, Bernd Schmidt  wrote:
> 
> Cc'ing Matt Thomas who is listed as the vax maintainer; most of the patch 
> should be reviewed by him IMO. If he is no longer active I'd frankly rather 
> deprecate the port rather than invest effort in keeping it running.
> 
>> Index: gcc/except.c
>> ===
>> RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/except.c,v
>> retrieving revision 1.3
>> diff -u -r1.3 except.c
>> --- gcc/except.c 23 Mar 2016 15:51:36 -  1.3
>> +++ gcc/except.c 28 Mar 2016 23:24:40 -
>> @@

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-04-01 Thread Bernd Schmidt 
Cc'ing Matt Thomas who is listed as the vax maintainer; most of the 
patch should be reviewed by him IMO. If he is no longer active I'd 
frankly rather deprecate the port rather than invest effort in keeping 
it running.



Index: gcc/except.c
===
RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/except.c,v
retrieving revision 1.3
diff -u -r1.3 except.c
--- gcc/except.c23 Mar 2016 15:51:36 -  1.3
+++ gcc/except.c28 Mar 2016 23:24:40 -
@@ -2288,7 +2288,8 @@
  #endif
  {
  #ifdef EH_RETURN_HANDLER_RTX
-  emit_move_insn (EH_RETURN_HANDLER_RTX, crtl->eh.ehr_handler);
+  rtx insn = emit_move_insn (EH_RETURN_HANDLER_RTX, crtl->eh.ehr_handler);
+  RTX_FRAME_RELATED_P (insn) = 1;  // XXX FIXME in VAX backend?
  #else
error ("__builtin_eh_return not supported on this target");
  #endif


This part looks highly suspicious and I think there needs to be further 
analysis.



Bernd

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-03-31 Thread Jake Hamby 
Hi JBG,

Thanks for the interest! Unfortunately, I need a few more days to work on this 
patch to clean it up and fix a few more bugs, then I'll send out a new version 
to NetBSD port-vax for testing, with ChangeLog entry. Please consider what I 
sent out earlier to be a work-in-progress at this point.

The version I have on my machine is now generating bad code, after trying to 
change a few "clobbers" to "compares", so I need to fix those bugs and also 
further clean up some stuff that I know is broken. For example, there's some 
old code in vax.c marked "#if HOST_BITS_PER_WIDE_INT == 32" and "if 
(HOST_BITS_PER_WIDE_INT == 32)" that will never be used because HOST_WIDE_INT 
is now always 64 (in hwint.h). I found another bug in a NetBSD command 
(/usr/sbin/pkg_info) processing command-line arguments in main() that goes away 
at "-O0". That bug should be easy to track down considering the small size of 
the program and that it's failing immediately in main().

There's one more thing that's broken in the VAX backend which I'd *really* like 
to fix: GCC can't compile many of its own files at -O2, as well as a few other 
.c files in the NetBSD tree, because it can't expand an insn pattern. The 
Makefiles have hacks to add "-O0" on VAX, and when I remove that workaround, I 
get GCC assertion failures, all of the form:

/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c: In function 
'void maybe_emit_chk_warning(tree, built_in_function)':
/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c:11549:1: error: 
unrecognizable insn:
 }
 ^
(insn 295 294 296 25 (set (reg:SI 111)
(subreg:SI (mem:DI (plus:SI (mult:SI (reg:SI 109)
(const_int 8 [0x8]))
(reg/f:SI 45 [ D.85015 ])) [7 *_98+0 S8 A32]) 4)) 
/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/wide-int.h:799 -1
 (nil))
/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c:11549:1: 
internal compiler error: in extract_insn, at recog.c:2343
0xbd0365 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/rtl-error.c:110
0xbd03fa _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/rtl-error.c:118
0xb92a2d extract_insn(rtx_insn*)

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/recog.c:2343
0x9612cd instantiate_virtual_regs_in_insn

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:1598
0x9612cd instantiate_virtual_regs

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:1966
0x9612cd execute

/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:2015

The failures all seem to be related to trying to read a value from an array of 
64-bit values and loading it into a 32-bit register. It seems like there should 
be a special insn defined for this sort of array access, since VAX has mova* 
and pusha* variants to set a value from an address plus an index into a byte, 
word, long, or 64-bit array (it uses movab/pushab, put not the other variants). 
The addressing modes, constraints, and predicates all get very complicated, and 
I still need to understand a bit better what is actually required, and what 
could be simplified and cleaned up.

If anyone has suggestions on how to define an instruction that would solve the 
previous failure, please let me know. Even without a special pattern for the 
"(plus:SI (mult:SI (reg:SI) (const_int 8)))", it should be able to generate 
something. It seems like it's expanding something and then the insn that's 
supposed to go with it isn't matching.

I tried adding define_insns for "movstrictsi" and for "truncdisi2", hoping that 
one of them would solve the "(set (reg:SI (subreg:SI (mem:DI (...)" part of 
the situation, but it didn't help. The "(subreg:SI)" stuff is strange, and I 
don't understand exactly what GCC is expecting the backend to define. I'll keep 
working on things and as soon as I have something that I think is in a 
contributable state and doesn't generate bad code, I'll email it.

Best regards,
Jake

> On Mar 31, 2016, at 07:30, Jan-Benedict Glaw  wrote:
> 
> Hi Jake!
> 
> On Mon, 2016-03-28 16:34:56 -0700, Jake Hamby  wrote:
>> Amazingly enough, my patch worked well enough that my NetBSD VAX
>> kernel built with GCC 5.3 is no longer crashing. I feel pretty good
>> about what I have so far so here's the complete diff for both the
>> C++ exception fix and the bad condition codes optimizer bug. It
>> should be good enough to check into NetBSD current, at least, and I
>> believe it does fix most, if not all, of the bad code generation
>> bugs with optimization on VAX.
> 
> I'd like to suggest to also Cc Matt Thomas , at
> least once the patch is tested with

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-03-31 Thread Jeff Law 

On 03/31/2016 08:30 AM, Jan-Benedict Glaw wrote:

Hi Jake!

On Mon, 2016-03-28 16:34:56 -0700, Jake Hamby  wrote:

Amazingly enough, my patch worked well enough that my NetBSD VAX
kernel built with GCC 5.3 is no longer crashing. I feel pretty good
about what I have so far so here's the complete diff for both the
C++ exception fix and the bad condition codes optimizer bug. It
should be good enough to check into NetBSD current, at least, and I
believe it does fix most, if not all, of the bad code generation
bugs with optimization on VAX.


I'd like to suggest to also Cc Matt Thomas , at
least once the patch is tested with GCC trunk/HEAD/master, instead of
5.3.  There isn't probably much of a difference, but you've done
substancial and important work here, so let's see it's applicable to
upstream GCC.

   And keep in mind that a ChangeLog entry is also needed.

FWIW, I put this in my gcc-7 queue.
jeff

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-03-31 Thread Jan-Benedict Glaw 
Hi Jake!

On Mon, 2016-03-28 16:34:56 -0700, Jake Hamby  wrote:
> Amazingly enough, my patch worked well enough that my NetBSD VAX
> kernel built with GCC 5.3 is no longer crashing. I feel pretty good
> about what I have so far so here's the complete diff for both the
> C++ exception fix and the bad condition codes optimizer bug. It
> should be good enough to check into NetBSD current, at least, and I
> believe it does fix most, if not all, of the bad code generation
> bugs with optimization on VAX.

I'd like to suggest to also Cc Matt Thomas , at
least once the patch is tested with GCC trunk/HEAD/master, instead of
5.3.  There isn't probably much of a difference, but you've done
substancial and important work here, so let's see it's applicable to
upstream GCC.

  And keep in mind that a ChangeLog entry is also needed.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:   Ich hatte in letzter Zeit ein bißchen viel Realitycheck.
the second  :   Langsam möchte ich mal wieder weiterträumen können.
 -- Maximilian Wilhelm (18. Mai 2005, #lug-owl.de)


signature.asc
Description: Digital signature

Patches to fix optimizer bug & C++ exceptions for GCC VAX backend

2016-03-28 Thread Jake Hamby 
Amazingly enough, my patch worked well enough that my NetBSD VAX kernel built 
with GCC 5.3 is no longer crashing. I feel pretty good about what I have so far 
so here's the complete diff for both the C++ exception fix and the bad 
condition codes optimizer bug. It should be good enough to check into NetBSD 
current, at least, and I believe it does fix most, if not all, of the bad code 
generation bugs with optimization on VAX.

-Jake

Index: gcc/except.c
===
RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/except.c,v
retrieving revision 1.3
diff -u -r1.3 except.c
--- gcc/except.c23 Mar 2016 15:51:36 -  1.3
+++ gcc/except.c28 Mar 2016 23:24:40 -
@@ -2288,7 +2288,8 @@
 #endif
 {
 #ifdef EH_RETURN_HANDLER_RTX
-  emit_move_insn (EH_RETURN_HANDLER_RTX, crtl->eh.ehr_handler);
+  rtx insn = emit_move_insn (EH_RETURN_HANDLER_RTX, crtl->eh.ehr_handler);
+  RTX_FRAME_RELATED_P (insn) = 1;  // XXX FIXME in VAX backend?
 #else
   error ("__builtin_eh_return not supported on this target");
 #endif
Index: gcc/config/vax/builtins.md
===
RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/config/vax/builtins.md,v
retrieving revision 1.5
diff -u -r1.5 builtins.md
--- gcc/config/vax/builtins.md  24 Jan 2016 09:43:34 -  1.5
+++ gcc/config/vax/builtins.md  28 Mar 2016 23:24:40 -
@@ -50,7 +50,8 @@
(ctz:SI (match_operand:SI 1 "general_operand" "nrmT")))
(set (cc0) (match_dup 0))]
   ""
-  "ffs $0,$32,%1,%0")
+  "ffs $0,$32,%1,%0"
+  [(set_attr "cc" "clobber")])
 
 (define_expand "sync_lock_test_and_set"
   [(set (match_operand:VAXint 0 "nonimmediate_operand" "=")
@@ -88,7 +89,8 @@
   (match_dup 1))
  (const_int 1))])]
   ""
-  "jbssi %1,%0,%l2")
+  "jbssi %1,%0,%l2"
+  [(set_attr "cc" "none")])
 
 (define_insn "jbbssihi"
   [(parallel
@@ -105,7 +107,8 @@
   (match_dup 1))
  (const_int 1))])]
   ""
-  "jbssi %1,%0,%l2")
+  "jbssi %1,%0,%l2"
+  [(set_attr "cc" "none")])
 
 (define_insn "jbbssisi"
   [(parallel
@@ -122,8 +125,8 @@
   (match_dup 1))
  (const_int 1))])]
   ""
-  "jbssi %1,%0,%l2")
-
+  "jbssi %1,%0,%l2"
+  [(set_attr "cc" "none")])
 
 (define_expand "sync_lock_release"
   [(set (match_operand:VAXint 0 "memory_operand" "+m")
@@ -160,7 +163,8 @@
   (match_dup 1))
  (const_int 0))])]
   ""
-  "jbcci %1,%0,%l2")
+  "jbcci %1,%0,%l2"
+  [(set_attr "cc" "none")])
 
 (define_insn "jbbccihi"
   [(parallel
@@ -177,7 +181,8 @@
   (match_dup 1))
  (const_int 0))])]
   ""
-  "jbcci %1,%0,%l2")
+  "jbcci %1,%0,%l2"
+  [(set_attr "cc" "none")])
 
 (define_insn "jbbccisi"
   [(parallel
@@ -194,4 +199,5 @@
   (match_dup 1))
  (const_int 0))])]
   ""
-  "jbcci %1,%0,%l2")
+  "jbcci %1,%0,%l2"
+  [(set_attr "cc" "none")])
Index: gcc/config/vax/elf.h
===
RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/config/vax/elf.h,v
retrieving revision 1.6
diff -u -r1.6 elf.h
--- gcc/config/vax/elf.h23 Mar 2016 15:51:37 -  1.6
+++ gcc/config/vax/elf.h28 Mar 2016 23:24:40 -
@@ -26,7 +26,7 @@
 #define REGISTER_PREFIX "%"
 #define REGISTER_NAMES \
   { "%r0", "%r1",  "%r2",  "%r3", "%r4", "%r5", "%r6", "%r7", \
-"%r8", "%r9", "%r10", "%r11", "%ap", "%fp", "%sp", "%pc", }
+"%r8", "%r9", "%r10", "%r11", "%ap", "%fp", "%sp", "%pc", "%psw", }
 
 #undef SIZE_TYPE
 #define SIZE_TYPE "long unsigned int"
@@ -45,18 +45,8 @@
count pushed by the CALLS and before the start of the saved registers.  */
 #define INCOMING_FRAME_SP_OFFSET 0
 
-/* Offset from the frame pointer register value to the top of the stack.  */
-#define FRAME_POINTER_CFA_OFFSET(FNDECL) 0
-
-/* We use R2-R5 (call-clobbered) registers for exceptions.  */
-#define EH_RETURN_DATA_REGNO(N) ((N) < 4 ? (N) + 2 : INVALID_REGNUM)
-
-/* Place the top of the stack for the DWARF2 EH stackadj value.  */
-#define EH_RETURN_STACKADJ_RTX \
-  gen_rtx_MEM (SImode, \
-  plus_constant (Pmode,\
- gen_rtx_REG (Pmode, FRAME_POINTER_REGNUM),\
- -4))
+/* We use R2-R3 (call-clobbered) registers for exceptions.  */
+#define EH_RETURN_DATA_REGNO(N) ((N) < 2 ? (N) + 2 : INVALID_REGNUM)
 
 /* Simple store the return handler into the call frame.  */
 #define EH_RETURN_HANDLER_RTX  \
@@ -66,10 +56,6 @@
  16))
 
 
-/* Reserve the top of the stack for exception handler stackadj value.  */
-#undef STARTING_FRAME_OFFSET
-#define STARTING_FRAME_OFFSET -4
-
 /* The VAX wants no space