[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[Hendrik Greving via Phabricator via cfe-commits]

hgreving added a comment.

In D74183#1942262 , @nikic wrote:

> In D74183#1941741 , @efriedma wrote:
>
> > If it's just tramp3d-v4, I'm not that concerned... but that's a weird 
> > result.  On x86 in particular, alignment markings have almost no effect on 
> > optimization, generally.
>
>
> I've just looked at the IR diff for tramp3d-v4 and it turns out that the root 
> cause is an old friend of mine: The insertion of alignment assumptions during 
> inlining 
> (https://github.com/llvm/llvm-project/blob/b58902bc72c2b479b5ed27ec0d3422ba9782edbb/llvm/lib/Transforms/Utils/InlineFunction.cpp#L1139-L1173).
>  That is, the IR now contains many instances of this sequence:
>
>   %ptrint = ptrtoint %class.GuardLayers* %guards_m to i64
>   %maskedptr = and i64 %ptrint, 3
>   %maskcond = icmp eq i64 %maskedptr, 0
>   tail call void @llvm.assume(i1 %maskcond)
>   
>
> to preserve the alignment information. From a cursory look I cannot tell 
> whether these additional assumes also regress optimization (due to 
> multi-use), but given the size increase on the final binary it seems pretty 
> likely that this is the case.
>
> This preservation of alignment during inlining is the reason why we used to 
> not emit alignment information for pointer arguments in Rust for a long time: 
> It caused serious regressions in optimization and increased compile-time. 
> Nowadays we do emit alignment information, but set 
> `-preserve-alignment-assumptions-during-inlining=false` to prevent this 
> inlining behavior.
>
> I think for the purposes of this revision, this means that we should probably 
> either a) default `preserve-alignment-assumptions-during-inlining` to false 
> (I would prefer this) or b) not emit the alignment unless it is smaller than 
> the ABI alignment (I guess this was what this patch originally did?)


We are having a problem with this very issue on a target not supporting a 
stack, with sroa bailing due to above, in our case causing a crash. Our only 
workaround for this is currently 
`preserve-alignment-assumptions-during-inlining` to false. We were actually 
wondering if this is causing performance issues on targets that due support a 
stack.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[Eli Friedman via Phabricator via cfe-commits]

efriedma added subscribers: hfinkel, jdoerfert.
efriedma added a comment.

That makes sense.

I would slightly lean towards not generating the assumptions, given the current 
state of assumptions and the likely benefit in this context.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Yeah, if emitting alignment assumptions in inlining is causing regressions when 
frontends provide better information, those assumptions need to be reverted 
until they can be fixed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D74183#1941741 , @efriedma wrote:

> If it's just tramp3d-v4, I'm not that concerned... but that's a weird result. 
>  On x86 in particular, alignment markings have almost no effect on 
> optimization, generally.


I've just looked at the IR diff for tramp3d-v4 and it turns out that the root 
cause is an old friend of mine: The insertion of alignment assumptions during 
inlining 
(https://github.com/llvm/llvm-project/blob/b58902bc72c2b479b5ed27ec0d3422ba9782edbb/llvm/lib/Transforms/Utils/InlineFunction.cpp#L1139-L1173).
 That is, the IR now contains many instances of this sequence:

  %ptrint = ptrtoint %class.GuardLayers* %guards_m to i64
  %maskedptr = and i64 %ptrint, 3
  %maskcond = icmp eq i64 %maskedptr, 0
  tail call void @llvm.assume(i1 %maskcond)

to preserve the alignment information. From a cursory look I cannot tell 
whether these additional assumes also regress optimization (due to multi-use), 
but given the size increase on the final binary it seems pretty likely that 
this is the case.

This preservation of alignment during inlining is the reason why we used to not 
emit alignment information for pointer arguments in Rust for a long time: It 
caused serious regressions in optimization and increased compile-time. Nowadays 
we do emit alignment information, but set 
`-preserve-alignment-assumptions-during-inlining=false` to prevent this 
inlining behavior.

I think for the purposes of this revision, this means that we should probably 
either a) default `preserve-alignment-assumptions-during-inlining` to false (I 
would prefer this) or b) not emit the alignment unless it is smaller than the 
ABI alignment (I guess this was what this patch originally did?)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

If it's just tramp3d-v4, I'm not that concerned... but that's a weird result.  
On x86 in particular, alignment markings have almost no effect on optimization, 
generally.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

For the record, this change caused an 1.5% compile-time regression on 
tramp3d-v4 
(http://llvm-compile-time-tracker.com/compare.php?from=43a6d285bfead762ac472a6e62beedc9f88bce89&to=de98cf92e301ab559a7417f1eca5cfa53624c9e1&stat=instructions).
 As there was also a 0.9% increase in code size, I assume that adding the 
alignment ends up having a non-trivial impact on optimization behavior for this 
benchmark and we end up generating more IR. So most likely this is fine and 
there's nothing to be done about it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D74183#1937426 , @efriedma wrote:

> I think we should remove the LangRef rule that says "sret" pointers have to 
> be dereferenceable/naturally aligned, and let the frontend add explicit 
> aligned/dereferenceable markings where appropriate.  (At that point, sret has 
> no target-independent meaning; it's just to manipulate the target ABI.)  It 
> would make the IR easier to understand, and resolves the interaction with 
> opaque pointers.


That might be reasonable, yeah.  And yeah, making the `dereferenceable` 
assumption explicit is going to be necessary with opaque pointer types 
eventually.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

I think we should remove the LangRef rule that says "sret" pointers have to be 
dereferenceable/naturally aligned, and let the frontend add explicit 
aligned/dereferenceable markings where appropriate.  (At that point, sret has 
no target-independent meaning; it's just to manipulate the target ABI.)  It 
would make the IR easier to understand, and resolves the interaction with 
opaque pointers.

That isn't to say we shouldn't make this change in clang; clang should do this, 
but at that point it would just be a performance enhancement, not required for 
correctness.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[John McCall via Phabricator via cfe-commits]

rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: wuzish.

I'm just going to assume the test changes look good; thank you for taking the 
time to do this.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2077
+getDataLayout().getABITypeAlignment(getTypes().ConvertType(RetTy)))
+  SRETAttrs.addAlignmentAttr(Align);
 ArgAttrs[IRFunctionArgs.getSRetArgNo()] =

rjmccall wrote:
> dexonsmith wrote:
> > scanon wrote:
> > > rjmccall wrote:
> > > > Why only when under-aligned?  Just to avoid churning tests?  I think we 
> > > > should apply this unconditionally.
> > > On mainstream architectures today, there's rarely a benefit to knowing 
> > > about higher alignment (e.g. MOVUPS is just as fast as MOVAPS if the 
> > > address is actually aligned), so we won't see significant perf wins from 
> > > preserving over-alignment in most cases, but it also doesn't cost us 
> > > anything AFAICT and could deliver wins in some specific cases (e.g. AVX 
> > > on SNB and IVB, where I think we split underaligned 256b stores into two 
> > > 128b chunks).
> > > 
> > > So, yeah, I think we ought to simply unconditionally add the alignment to 
> > > the sret.
> > @rjmccall, are you seeing a reason to add the attribute when the implicit 
> > one is correct (neither over-aligned nor under-aligned)?  If so, it seems 
> > to me like the added noise would make the IR harder to read.
> Well, first, I think we're going to end up needing an alignment there in all 
> cases eventually because of opaque pointer types.  But I also think it's just 
> cleaner and more testable to add the attribute in all cases instead of 
> leaving it off when the IR type happens to have the right alignment, which 
> can be very sensitive to the target.
In general, I think frontends should *never* be leaving it up to LLVM to infer 
alignment based on IR types, and this is part-and-parcel with that.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2077
+getDataLayout().getABITypeAlignment(getTypes().ConvertType(RetTy)))
+  SRETAttrs.addAlignmentAttr(Align);
 ArgAttrs[IRFunctionArgs.getSRetArgNo()] =

rjmccall wrote:
> rjmccall wrote:
> > dexonsmith wrote:
> > > scanon wrote:
> > > > rjmccall wrote:
> > > > > Why only when under-aligned?  Just to avoid churning tests?  I think 
> > > > > we should apply this unconditionally.
> > > > On mainstream architectures today, there's rarely a benefit to knowing 
> > > > about higher alignment (e.g. MOVUPS is just as fast as MOVAPS if the 
> > > > address is actually aligned), so we won't see significant perf wins 
> > > > from preserving over-alignment in most cases, but it also doesn't cost 
> > > > us anything AFAICT and could deliver wins in some specific cases (e.g. 
> > > > AVX on SNB and IVB, where I think we split underaligned 256b stores 
> > > > into two 128b chunks).
> > > > 
> > > > So, yeah, I think we ought to simply unconditionally add the alignment 
> > > > to the sret.
> > > @rjmccall, are you seeing a reason to add the attribute when the implicit 
> > > one is correct (neither over-aligned nor under-aligned)?  If so, it seems 
> > > to me like the added noise would make the IR harder to read.
> > Well, first, I think we're going to end up needing an alignment there in 
> > all cases eventually because of opaque pointer types.  But I also think 
> > it's just cleaner and more testable to add the attribute in all cases 
> > instead of leaving it off when the IR type happens to have the right 
> > alignment, which can be very sensitive to the target.
> In general, I think frontends should *never* be leaving it up to LLVM to 
> infer alignment based on IR types, and this is part-and-parcel with that.
> I think we're going to end up needing an alignment there in all cases 
> eventually because of opaque pointer types.

That's a great point.  In that case I don't have a strong opinion.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2077
+getDataLayout().getABITypeAlignment(getTypes().ConvertType(RetTy)))
+  SRETAttrs.addAlignmentAttr(Align);
 ArgAttrs[IRFunctionArgs.getSRetArgNo()] =

dexonsmith wrote:
> scanon wrote:
> > rjmccall wrote:
> > > Why only when under-aligned?  Just to avoid churning tests?  I think we 
> > > should apply this unconditionally.
> > On mainstream architectures today, there's rarely a benefit to knowing 
> > about higher alignment (e.g. MOVUPS is just as fast as MOVAPS if the 
> > address is actually aligned), so we won't see significant perf wins from 
> > preserving over-alignment in most cases, but it also doesn't cost us 
> > anything AFAICT and could deliver wins in some specific cases (e.g. AVX on 
> > SNB and IVB, where I think we split underaligned 256b stores into two 128b 
> > chunks).
> > 
> > So, yeah, I think we ought to simply unconditionally add the alignment to 
> > the sret.
> @rjmccall, are you seeing a reason to add the attribute when the implicit one 
> is correct (neither over-aligned nor under-aligned)?  If so, it seems to me 
> like the added noise would make the IR harder to read.
Well, first, I think we're going to end up needing an alignment there in all 
cases eventually because of opaque pointer types.  But I also think it's just 
cleaner and more testable to add the attribute in all cases instead of leaving 
it off when the IR type happens to have the right alignment, which can be very 
sensitive to the target.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2077
+getDataLayout().getABITypeAlignment(getTypes().ConvertType(RetTy)))
+  SRETAttrs.addAlignmentAttr(Align);
 ArgAttrs[IRFunctionArgs.getSRetArgNo()] =

scanon wrote:
> rjmccall wrote:
> > Why only when under-aligned?  Just to avoid churning tests?  I think we 
> > should apply this unconditionally.
> On mainstream architectures today, there's rarely a benefit to knowing about 
> higher alignment (e.g. MOVUPS is just as fast as MOVAPS if the address is 
> actually aligned), so we won't see significant perf wins from preserving 
> over-alignment in most cases, but it also doesn't cost us anything AFAICT and 
> could deliver wins in some specific cases (e.g. AVX on SNB and IVB, where I 
> think we split underaligned 256b stores into two 128b chunks).
> 
> So, yeah, I think we ought to simply unconditionally add the alignment to the 
> sret.
@rjmccall, are you seeing a reason to add the attribute when the implicit one 
is correct (neither over-aligned nor under-aligned)?  If so, it seems to me 
like the added noise would make the IR harder to read.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[Steve Canon via Phabricator via cfe-commits]

scanon added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2077
+getDataLayout().getABITypeAlignment(getTypes().ConvertType(RetTy)))
+  SRETAttrs.addAlignmentAttr(Align);
 ArgAttrs[IRFunctionArgs.getSRetArgNo()] =

rjmccall wrote:
> Why only when under-aligned?  Just to avoid churning tests?  I think we 
> should apply this unconditionally.
On mainstream architectures today, there's rarely a benefit to knowing about 
higher alignment (e.g. MOVUPS is just as fast as MOVAPS if the address is 
actually aligned), so we won't see significant perf wins from preserving 
over-alignment in most cases, but it also doesn't cost us anything AFAICT and 
could deliver wins in some specific cases (e.g. AVX on SNB and IVB, where I 
think we split underaligned 256b stores into two 128b chunks).

So, yeah, I think we ought to simply unconditionally add the alignment to the 
sret.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2077
+getDataLayout().getABITypeAlignment(getTypes().ConvertType(RetTy)))
+  SRETAttrs.addAlignmentAttr(Align);
 ArgAttrs[IRFunctionArgs.getSRetArgNo()] =

Why only when under-aligned?  Just to avoid churning tests?  I think we should 
apply this unconditionally.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74183/new/

https://reviews.llvm.org/D74183



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74183: [IRGen] Add an alignment attribute to underaligned sret parameters

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington created this revision.
erik.pilkington added reviewers: rjmccall, scanon.
Herald added subscribers: ributzka, dexonsmith, jkorous.

Without this, LLVM will assume the pointer has the type's alignment, which is 
undefined if the value is actually underaligned.

rdar://58316406


https://reviews.llvm.org/D74183

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/aligned-sret.c
  clang/test/CodeGen/arm-varargs.c
  clang/test/CodeGen/arm64-arguments.c
  clang/test/CodeGen/arm64_32.c
  clang/test/CodeGen/systemz-abi-vector.c

Index: clang/test/CodeGen/systemz-abi-vector.c
===
--- clang/test/CodeGen/systemz-abi-vector.c
+++ clang/test/CodeGen/systemz-abi-vector.c
@@ -71,7 +71,7 @@
 
 v32i8 pass_v32i8(v32i8 arg) { return arg; }
 // CHECK-LABEL: define void @pass_v32i8(<32 x i8>* noalias sret %{{.*}}, <32 x i8>* %0)
-// CHECK-VECTOR-LABEL: define void @pass_v32i8(<32 x i8>* noalias sret %{{.*}}, <32 x i8>* %0)
+// CHECK-VECTOR-LABEL: define void @pass_v32i8(<32 x i8>* noalias sret align 8 %{{.*}}, <32 x i8>* %0)
 
 v1i16 pass_v1i16(v1i16 arg) { return arg; }
 // CHECK-LABEL: define void @pass_v1i16(<1 x i16>* noalias sret %{{.*}}, <1 x i16>* %0)
@@ -168,7 +168,7 @@
 struct agg_v32i8 { v32i8 a; };
 struct agg_v32i8 pass_agg_v32i8(struct agg_v32i8 arg) { return arg; }
 // CHECK-LABEL: define void @pass_agg_v32i8(%struct.agg_v32i8* noalias sret %{{.*}}, %struct.agg_v32i8* %{{.*}})
-// CHECK-VECTOR-LABEL: define void @pass_agg_v32i8(%struct.agg_v32i8* noalias sret %{{.*}}, %struct.agg_v32i8* %{{.*}})
+// CHECK-VECTOR-LABEL: define void @pass_agg_v32i8(%struct.agg_v32i8* noalias sret align 8 %{{.*}}, %struct.agg_v32i8* %{{.*}})
 
 
 // Verify that the following are *not* vector-like aggregate types
@@ -379,7 +379,7 @@
 // CHECK: [[VA_ARG_ADDR:%[^ ]+]] = phi <32 x i8>** [ [[REG_ADDR]], %{{.*}} ], [ [[MEM_ADDR]], %{{.*}} ]
 // CHECK: [[INDIRECT_ARG:%[^ ]+]] = load <32 x i8>*, <32 x i8>** [[VA_ARG_ADDR]]
 // CHECK: ret void
-// CHECK-VECTOR-LABEL: define void @va_v32i8(<32 x i8>* noalias sret %{{.*}}, %struct.__va_list_tag* %{{.*}})
+// CHECK-VECTOR-LABEL: define void @va_v32i8(<32 x i8>* noalias sret align 8 %{{.*}}, %struct.__va_list_tag* %{{.*}})
 // CHECK-VECTOR: [[REG_COUNT_PTR:%[^ ]+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %{{.*}}, i32 0, i32 0
 // CHECK-VECTOR: [[REG_COUNT:%[^ ]+]] = load i64, i64* [[REG_COUNT_PTR]]
 // CHECK-VECTOR: [[FITS_IN_REGS:%[^ ]+]] = icmp ult i64 [[REG_COUNT]], 5
@@ -576,7 +576,7 @@
 // CHECK: [[VA_ARG_ADDR:%[^ ]+]] = phi %struct.agg_v32i8** [ [[REG_ADDR]], %{{.*}} ], [ [[MEM_ADDR]], %{{.*}} ]
 // CHECK: [[INDIRECT_ARG:%[^ ]+]] = load %struct.agg_v32i8*, %struct.agg_v32i8** [[VA_ARG_ADDR]]
 // CHECK: ret void
-// CHECK-VECTOR-LABEL: define void @va_agg_v32i8(%struct.agg_v32i8* noalias sret %{{.*}}, %struct.__va_list_tag* %{{.*}})
+// CHECK-VECTOR-LABEL: define void @va_agg_v32i8(%struct.agg_v32i8* noalias sret align 8 %{{.*}}, %struct.__va_list_tag* %{{.*}})
 // CHECK-VECTOR: [[REG_COUNT_PTR:%[^ ]+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %{{.*}}, i32 0, i32 0
 // CHECK-VECTOR: [[REG_COUNT:%[^ ]+]] = load i64, i64* [[REG_COUNT_PTR]]
 // CHECK-VECTOR: [[FITS_IN_REGS:%[^ ]+]] = icmp ult i64 [[REG_COUNT]], 5
Index: clang/test/CodeGen/arm64_32.c
===
--- clang/test/CodeGen/arm64_32.c
+++ clang/test/CodeGen/arm64_32.c
@@ -27,4 +27,4 @@
 
 typedef float __attribute__((ext_vector_type(16))) v16f32;
 v16f32 func(v16f32 in) { return in; }
-// CHECK: define void @func(<16 x float>* noalias sret {{%.*}}, <16 x float> {{%.*}})
+// CHECK: define void @func(<16 x float>* noalias sret align 16 {{%.*}}, <16 x float> {{%.*}})
Index: clang/test/CodeGen/arm64-arguments.c
===
--- clang/test/CodeGen/arm64-arguments.c
+++ clang/test/CodeGen/arm64-arguments.c
@@ -181,9 +181,9 @@
 // CHECK: define <4 x float> @f1_1(<4 x float> %{{.*}})
 T_float32x4 f1_1(T_float32x4 a0) { return a0; }
 // Vector with length bigger than 16-byte is illegal and is passed indirectly.
-// CHECK: define void @f1_2(<8 x float>* noalias sret  %{{.*}}, <8 x float>* %0)
+// CHECK: define void @f1_2(<8 x float>* noalias sret align 16 %{{.*}}, <8 x float>* %0)
 T_float32x8 f1_2(T_float32x8 a0) { return a0; }
-// CHECK: define void @f1_3(<16 x float>* noalias sret %{{.*}}, <16 x float>* %0)
+// CHECK: define void @f1_3(<16 x float>* noalias sret align 16 %{{.*}}, <16 x float>* %0)
 T_float32x16 f1_3(T_float32x16 a0) { return a0; }
 
 // Testing alignment with aggregates: HFA, aggregates with size <= 16 bytes and
Index: clang/test/CodeGen/arm-varargs.c
===
--- clang/test/CodeGen/arm-varargs.c
+++ clang/test/CodeGen/arm-varargs.c
@@ -201,7 +201,7 @@
   long long val;
 } underaligned_long_long_struct;
 undera