On Fri, Nov 15, 2024 at 1:45 PM Jan Hubicka <hubi...@ucw.cz> wrote: > > > > > The patch only ever skips just one conversion, never a chain of them and > > deliberately so, for the reasons shown in the example. > > > > However, I have just realized that combining pass_through jump functions > > during inlining may unfortunately have exactly the same effect, so we > > indeed need to be more careful. > > Ah, right. I was thinking if I can trigger someting like this and this > option did not came to my mind. > > > > The motivating example converts a bool (integer with precision one) to > > an int, so what about the patch below which allows converting between > > integers and to a higher precision? (Assuming the patch will pass > > bootstrap and testing on x86_64-linux which is underway). > > Allowing only conversion that monotonously increase precision looks. > Perhaps Richi may have opinion here. > In a way this is similar to what we do in gimple_call_builtin that has > some type checking and also allows widening conversions. So perhaps > this can be unified. > > I just noticed that testusite has few examples that, for example, define > > void *calloc (long, long) > > and this makes the test fail since parameter is really unsigned long > and in the turn we disable some calloc optimizations even though this > does not affect code generation. Some passes use > gimple_call_builtin while other look up callee decl by hand.
I think all conversions that are not value changing (based on incoming range) are OK. Even signed int with [3, 10] -> unsigned char [3, 10] would be OK. But signed int with [-1, 1] -> unsigned char [0, 1] [ 0xff ] might cause problems. Richard. > > Honza
