The "aligned" attribute can only increase the alignment of a struct, or struct member, unless it's used together with the "packed" attribute, or used as a part of a typedef, in which case, the "aligned" attribute can both increase and decrease alignment.
That said, we expect:
- "aligned" attribute alone: does not interfere with the alignment upgrade instrumented by the AIX "power" alignment rule,
- "aligned" attribute + typedef: overrides any computed alignment,
- "aligned" attribute + "packed" attribute: overrides any computed alignment.
The old implementation achieved 2 and 3, but didn't get 1 right, in that any field marked attribute "aligned" would not go through the alignment upgrade.
Okay, so first off, the comment and variable names here make this sound very general when in fact this computation is only relevant to the AIX alignment upgrade logic. Also, please do not introduce new variables with broad scope named things like Ty that are actually referring to a very specific type and not, say, the unadulterated type of the field.
It seems to me that the right way to think about this is that, while the AIX power alignment upgrade considers whether field type alignment is "required", it uses a different condition than the standard rule when making that decision. It's important to understand what that rule is exactly, and we can't see that from the current test cases. In particular, attributes on fields that define structs inline actually end up applying to both the field and the struct, which confounds unrelated issues. Consider:
Regardless, I don't think this check for a typedef works; it's bypassing quite a bit of recursive logic for computing whether type alignment is required. For example, you could have an explicitly aligned typedef of an array type, and you'll lose that typedef here.