en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Assembler/byref-parse-error-2.ll#5e999cbe IR: Define byref parameter attributeThis allows tracking the in-memory type of a pointer argument to afunction for ABI purposes. This is essentially a stripped down versionof byval to remove some of the stack-copy implications in itsdefinition.This includes the base IR changes, and some tests for places where itshould be treated similarly to byval. Codegen support will be in afuture patch.My original attempt at solving some of these problems was to repurposebyval with a different address space from the stack. However, it istechnically permitted for the callee to introduce a write to theargument, although nothing does this in reality. There is also talk ofremoving and replacing the byval attribute, so a new attribute wouldneed to take its place anyway.This is intended avoid some optimization issues with the currenthandling of aggregate arguments, as well as fixes inflexibilty in howfrontends can specify the kernel ABI. The most honest representationof the amdgpu_kernel convention is to expose all kernel arguments asloads from constant memory. Today, these are raw, SSA Argument valuesand codegen is responsible for turning these into loads.Background:There currently isn't a satisfactory way to represent how argumentsfor the amdgpu_kernel calling convention are passed. In reality,arguments are passed in a single, flat, constant memory bufferimplicitly passed to the function. It is also illegal to call thisfunction in the IR, and this is only ever invoked by a driver of somekind.It does not make sense to have a stack passed parameter in thiscontext as is implied by byval. It is never valid to write to thekernel arguments, as this would corrupt the inputs seen by otherdispatches of the kernel. These argumets are also not in the sameaddress space as the stack, so a copy is needed to an alloca. From asource C-like language, the kernel parameters are invisible.Semantically, a copy is always required from the constant argumentmemory to a mutable variable.The current clang calling convention lowering emits raw values,including aggregates into the function argument list, since usingbyval would not make sense. This has some unfortunate consequences forthe optimizer. In the aggregate case, we end up with an aggregatestore to alloca, which both SROA and instcombine turn into a store ofeach aggregate field. The optimizer never pieces this back together tosee that this is really just a copy from constant memory, so we end upstuck with expensive stack usage.This also means the backend dictates the alignment of arguments, andarbitrarily picks the LLVM IR ABI type alignment. By allowing anexplicit alignment, frontends can make better decisions. For example,there's real no advantage to an aligment higher than 4, so a frontendcould choose to compact the argument layout. Similarly, there is ahigh penalty to using an alignment lower than 4, so a frontend couldopt into more padding for small arguments.Another design consideration is when it is appropriate to expose thefact that these arguments are all really passed in adjacentmemory. Currently we have a late IR optimization pass in codegen torewrite the kernel argument values into explicit loads to enablevectorization. In most programs, unrelated argument loads can bemerged together. However, exposing this property directly from thefrontend has some disadvantages. We still need a way to track theoriginal argument sizes and alignments to report to the driver. I findusing some side-channel, metadata mechanism to track thisunappealing. If the kernel arguments were exposed as a single bufferto begin with, alias analysis would be unaware that the padding bitsbetewen arguments are meaningless. Another family of problems is thereare still some gaps in replacing all of the available parameterattributes with metadata equivalents once lowered to loads.The immediate plan is to start using this new attribute to handle allaggregate argumets for kernels. Long term, it makes sense to migrateall kernel arguments, including scalars, to be passed indirectly inthe same manner.Additional context is in D79744. List of files: /llvm-project-15.0.7/llvm/test/Assembler/byref-parse-error-2.ll Fri, 05 Jun 2020 20:58:47 +0000 Matt Arsenault <Matthew.Arsenault@amd.com>