On Mon, Aug 10, 2009 at 2:53 PM, Michael Matz<m...@suse.de> wrote: > Hi, > > On Fri, 7 Aug 2009, Richard Henderson wrote: > >> On 08/07/2009 12:31 PM, Richard Guenther wrote: >> > > L.N: >> > > exc_ptr.1 = EXC_PTR_EXPR (N); >> > > filter.1 = FILTER_EXPR (N); >> > >> > Does the above have >> > virtual operands, thus are there any aliases to whatever EXP_PTR_EXPR >> > or FILTER_EXPR load? >> >> No and no. They will eventually resolve to pseudos generated during >> rtl eh expansion. But to avoid silliness at the gimple level I don't >> want to allow them to appear at random. > > Shouldn't it be enough to have EXC_PTR_EXPR/FILTER_EXPR simply be builtin > functions with proper attributes. They wouldn't be moved upwards over the > EH edge because that would introduce effects after the throwing stmt, and > they wouldn't be moved downwards due to use-def relationships on > exc_ptr.1/filter.1 in the EH_DISPATCH/RESX uses.
What would these attributes be? If you want to have the builtin having side-effects it can't be pure or const. >> Ideally, the rtl would generate what it needs directly into exc_ptr.1, >> but I couldn't figure out any way to do that cleanly. In the end, >> generating an extra pseudo for register allocation to coalesce is not >> the worst sin I could commit here. >> >> > Can we CSE FILTER_EXPR (N) and EXC_PTR_EXPR (N)? >> >> Yes. > > Which also would just work with builtin functions of proper attributes. Which would require either pure or const attributes. Richard.
