This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is vec_init<mode> allowed to FAIL?


Jan Hoogerbrugge wrote:
I see however that no code is generated if trimedia_expand_vector_init()
returns 0 and the define_expand FAILs. I also see in other targets that a
vec_init always ends with a DONE. Could it be that vec_init is not allowed to
FAIL?

Grep for "vec_init", and we see that it is used in expr.c, store_constructor(), case VECTOR_TYPE. It calls optab_handler to set icode, and then at the end calls GEN_FCN (icode). There is no provision for the GEN_FCN (icode) call returning failure, so yes, vec_init is not allowed to fail.


This could probably be fixed with a little code rearrangement. For instance, you could try putting all code starting with the line that tests "need_to_clear && size > 0 && !vector" into a loop that iterates twice. If vector is not set, then we exit the loop after emitting code. If vector is set, and the GEN_FCN call succeeded, then we exit the loop. If vector is set, and the GEN_FCN call fails, then we clear vector, throw away any RTL that may have been emitted, and loop back for a second pass using the non-vector code, which always succeeds. Throwing away the temporary RTL can be accomplished by using start_sequence and end_sequence. There may also be other ways to fix this.

Jim


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]