Anything Amiga specific about -fshort-enums ?

bebbo / gcc

Bebbo's gcc-6-branch for m68k-amigaos

GNU General Public License v2.0

33 stars 11 forks source link

Anything Amiga specific about -fshort-enums ? #70

Closed mheyer32 closed 5 years ago

mheyer32 commented 5 years ago

In an attempt to make things a bit faster (smaller structs, smaller data for enums), I opted for -fshort-enums in ScummVM. Weird thing is: -fshort-enums it breaks ScummVM in a very subtle manner. It still largely runs, but the Tinsel engine (Discworld) starts having issues with pathfinding...

Now, before I dive deep into assembly, is there anything Amiga specific about -fshort-enums that I should know about? Anything I should look out for?

bebbo commented 5 years ago

no idea - sorry. If it runs ok with -fbbb=- then I'm the cause again

mheyer32 commented 5 years ago

Well, one data point: it got nothing to do with -fbbb; problem reproduces with -fbbb=-

mheyer32 commented 5 years ago

Oh, I think I know whats going on. The first crash happens in '__swbuf()' which is probably part of the runtime libs. If they are using enums and have not compiled with -fshort-enums, ScummVM will have a hard time calling into the runtime libs for anything that stores or accepts enums.

Is there a central point in the toolchain where the compile flags for the various runtlime libs are adjusted? I'd like to run a experiment to see if this could be made working by compiling the runtime libs with -fshort-enums, too.

Update: These seem to be the only enums in libnix:

./sources/headers/socket.h:typedef enum {LX_NONE, LX_AMITCP, LX_AS225} LX_NETWORK_TYPE; ./sources/headers/stdio.h:typedef enum {LX_FILE,LX_SOCKET} LX_FILE_TYPE;

bebbo commented 5 years ago

you might try CFLAGS_FOR_TARGET but also use -O2 otherwise exception handling seems to be broken

mheyer32 commented 5 years ago

adding -fshort-enums to CFLAGS_FOR_TARGET got rid of the issue.

Now I wonder if it's worth using -fshort-enums on m68k as standard (i.e. have it always enabled) ? Would it have any adverse side effects?

The Pro arguments are: less storage, tighter packing of enums, thus less bandwidth/better cache usage on our puny cpu. Con: ?

bebbo commented 5 years ago

no idea - short vs int is not always a win.

mheyer32 commented 5 years ago

Hold on, the problem did not go away... it just moved somewhere else... The pathfinding in Discworld now works while Sierra games don't even start up anymore. As if shifting things around a bit just moved the problem somewhere else. :-(

This might take a while to figure out.

mheyer32 commented 5 years ago

Re: "no idea - short vs int is not always a win."

In many (most?) cases enums are rather small and fit into just a byte.

bebbo commented 5 years ago

The compiler must always be able to determine the size using a forward declaration. Thus enums need a fixed size.
- Depending on the usage of enums its values are assigned or compared with int values. In case of short enums this requires proper conversion (e.g. and.l 0xffff,d0) and the resulting code is bigger and slower than using int enums
- Starting with 68040 short and int insns having the same speed

mheyer32 commented 5 years ago

I am still investigating issues with -fshort-enums;

After recent fixes inthe compiler, the issue has become more elusive. I'm starting to believe it might be a compiler bug :-)

The issue I mentioned in https://github.com/bebbo/gcc/issues/70#issuecomment-465459655 is not related. That was just assert() aborting and in turn my outdated libnix causing writes to NULL when writing to stderr.

mheyer32 commented 5 years ago

I tracked it down to a serialization issue in Tinsel. I think -fshort-enums is working fine.