FYI, I've already committed this because our other team needs this bug fix.
Marek On Thu, Aug 25, 2016 at 8:26 PM, Marek Olšák <mar...@gmail.com> wrote: > From: Marek Olšák <marek.ol...@amd.com> > > It crashes. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97413 > --- > src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c > b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c > index 71f52fd..4643e6d 100644 > --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c > +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c > @@ -552,22 +552,24 @@ static void emit_declaration(struct > lp_build_tgsi_context *bld_base, > * > * Note that 16 is the number of vector elements that > * LLVM will store in a register, so theoretically an > * array with up to 4 * 16 = 64 elements could be > * handled this way, but whether that's a good idea > * depends on VGPR register pressure elsewhere. > * > * FIXME: We shouldn't need to have the non-alloca > * code path for arrays. LLVM should be smart enough > to > * promote allocas into registers when profitable. > + * > + * LLVM 3.8 crashes with this. > */ > - if (array_size > 16) { > + if (HAVE_LLVM >= 0x0309 && array_size > 16) { > array_alloca = LLVMBuildAlloca(builder, > LLVMArrayType(bld_base->base.vec_type, > array_size), "array"); > ctx->temp_array_allocas[id] = array_alloca; > } > } > > if (!ctx->temps_count) { > ctx->temps_count = > bld_base->info->file_max[TGSI_FILE_TEMPORARY] + 1; > ctx->temps = MALLOC(TGSI_NUM_CHANNELS * > ctx->temps_count * sizeof(LLVMValueRef)); > -- > 2.7.4 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
