Change Details

This is an attempt to add support for intrinsic overloading on anonymous struct based types. This fixes PR38117 and will also be needed for the Full Restrict Patches (D68484). The main problem is that the intrinsic overloading name mangling is using 's_s' for anonymous structs. This patch changes this to 'sa_XXXXs' (with XXX a stable unique number, associated with the anonymous type). Implementation details: - The mapping is created on demand and kept in the LLVMContext. - Because of this, Intrinsic::getName needs an extra Module* argument. - I still kept the original two-argument 'Intrinsic::getName' around which keeps the original behavior (using s_s). (Main reason is that I did not want to change the LLVMIntrinsicGetName version, as I don't know how acceptable such a change is) - Intrinsic::getDeclaration and the verifier are now using the new version. Other notes: - A testcase is not yet included. I first want to get feedback if this is an acceptable approach to the problem

This is an attempt to add support for intrinsic overloading on anonymous struct based types. This fixes PR38117 and will also be needed for the Full Restrict Patches (D68484). The main problem is that the intrinsic overloading name mangling is using 's_s' for anonymous structs. This can result in identical intrinsic names for different function prototypes. This patch changes this by adding a '.XXXXX' to such names, ensuring that the name is unique. Implementation details: - The mapping is created on demand and kept in Module. - It also check for existing clashes and recycles potentially existing prototypes and declarations. - Because of extra data in Module, Intrinsic::getName needs an extra Module* argument and, for speed, an optional FunctionType* argument. - I still kept the original two-argument 'Intrinsic::getName' around which keeps the original behavior (providing the base name). (Main reason is that I did not want to change the LLVMIntrinsicGetName version, as I don't know how acceptable such a change is) - Intrinsic::getDeclaration and the verifier are now using the new version. Other notes: - A testcase is not yet included. I first want to get feedback if this is an acceptable approach to the problem - As far as I see, this should not suffer from stability issues. The count is only added for prototypes depending on at least one anonymous struct - The initial count starts from 0 for each intrinsic id. - In case of name clashes, I try to reuse existing names. - on second thought: the current mechanism does not prohibit associating different 'BaseName's to the same intrinsic id. In this case they still share the 'unique number count'. It could make sense to associate the unique number to the 'BaseName' instead of to the intrinsic id.

This is an attempt to add support for intrinsic overloading on anonymous struct based types. This fixes PR38117 and will also be needed for the Full Restrict Patches (D68484). The main problem is that the intrinsic overloading name mangling is using 's_s' for anonymous structs. This patch changes this to 'sa_XXXXs' (with XXX a stable unique numbercan result in identical intrinsic names for different function prototypes. This patch changes this by adding a '.XXXXX' to such names, associated withensuring that the anonymous type)name is unique. Implementation details: - The mapping is created on demand and kept in the LLVMContextModule. - It also check for existing clashes and recycles potentially existing prototypes and declarations. - Because of thisextra data in Module, Intrinsic::getName needs an extra Module* argument and, for speed, Intrinsic::getName needs an extra Modulan optional FunctionType* argument. - I still kept the original two-argument 'Intrinsic::getName' around which keeps the original behavior (using s_sproviding the base name). (Main reason is that I did not want to change the LLVMIntrinsicGetName version, as I don't know how acceptable such a change is) - Intrinsic::getDeclaration and the verifier are now using the new version. Other notes: - A testcase is not yet included. I first want to get feedback if this is an acceptable approach to the problem - As far as I see, this should not suffer from stability issues. The count is only added for prototypes depending on at least one anonymous struct - The initial count starts from 0 for each intrinsic id. - In case of name clashes, I try to reuse existing names. - on second thought: the current mechanism does not prohibit associating different 'BaseName's to the same intrinsic id. In this case they still share the 'unique number count'. It could make sense to associate the unique number to the 'BaseName' instead of to the intrinsic id.