[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	10/11/21 21:00:16

Modified files:
	cm3/m3-sys/m3cc/src/: m3makefile clean_marker.txt 
	cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c 

Log message:
	significant fixes for configure -enable-checking
	
	- Continue using bitfield_refs for load/store, but
	mark the parameter addressable.
	Hopefully this isn't as bad as volatile, though
	given how effective it is, I suspect it might be.
	We can do better in future using component/array_ref.
	
	- don't inline nested functions whose parents are not inlinable
	(e.g. parent has barrier label)
	
	- don't inline any function that manipulate static link (load/pop)
	
	- ie: nested functions can be inlined, but only in the absence
	of exception handling or accessing parent frame;
	i.e. when they are used for scoping the name of the function
	
	- remove a chunk in volatilize that had the tree types wrong
	
	- add another m3_cast, that I suspected was needed anyway
	but couldn't prove via an error, now I have seen it error
	
	- remove the recent addition of stabilize_reference,
	it makes me nervous; it might be an optimization
	or a deoptimization
	
	and then:
	- allow many optimizations that we previously did not allow,
	in fact, all of them, but suppress a new one, flag_tree_forwprop,
	which I suspect actually is a simple valuable one, but
	I think this is the right compromise at the moment.
	I'm "dancing" between types, optimizations, checking, and
	also disabling some checks.
	
	- enable the checking in all builds
	not quite all checking, as all is really really really slow,
	though we should find a way to run that occasionally
	
	We'll want to dial this down for release to speed it back up.
	
	I think for dialing it up, maybe dedicate a host or task,
	and don't have that one make releases/snapshots. It could
	be a second host of the same type as another, e.g. a second
	I386_LINUX host. (We also need to enable optimizations
	in Hudson sometimes.)
	
	Only tested on AMD64_DARWIN.