search for: setdefaultfnattribute

...idable, we'd need a completely new design for > enum attributes. > > As a result, this proposal only improves `llc` for string-based > attributes. I don't see that as a problem... the string-based > attributes are more flexible anyway. Maybe `Module` should only > allow `setDefaultFnAttribute()` for string attributes though? > > (Some more context on why enum attributes can't really be > overridden. This isn't just a problem for enum attributes that > are mutually exclusive. Consider: > > attributes defaults = { noreturn } > > Besides being somewhat...

Hi Duncan, Been thinking about this a bit and a few comments/questions. I may have misunderstood some things in your mail though so please feel free to explain at me :) > Changing `clang` to store target defaults on the module will allow us to > continue to override them when running `llc`. The right precedence > would be: > > 1. Explicit attributes set on the function. >

...completely new design for >> enum attributes. >> >> As a result, this proposal only improves `llc` for string-based >> attributes. I don't see that as a problem... the string-based >> attributes are more flexible anyway. Maybe `Module` should only >> allow `setDefaultFnAttribute()` for string attributes though? >> >> (Some more context on why enum attributes can't really be >> overridden. This isn't just a problem for enum attributes that >> are mutually exclusive. Consider: >> >> attributes defaults = { noreturn } >>...

...ompletely new design for >> enum attributes. >> >> As a result, this proposal only improves `llc` for string-based >> attributes. I don't see that as a problem... the string-based >> attributes are more flexible anyway. Maybe `Module` should only >> allow `setDefaultFnAttribute()` for string attributes though? >> >> (Some more context on why enum attributes can't really be >> overridden. This isn't just a problem for enum attributes that >> are mutually exclusive. Consider: >> >> attributes defaults = { noreturn } >&gt...