search for: getwhatev

...you've mentioned above may help, but I'm not sure if that's the > use pattern you had in mind. Actually yes, that's one of the things I rely on quite heavily in my AMDGPU changes. The AMDGPU backend already uses a pattern to implement subroutines that looks like this: class getWhatever<parameters> { type ret = ...; } This tends to work out in many cases because getWhatever<...>.ret is substituted early, but there are corner cases when you push it further, and I believe those are all fixed with the VarDefInit change I've described above. In any case, I'...

...y help, but I'm not sure if that's the > > use pattern you had in mind. > > Actually yes, that's one of the things I rely on quite heavily in my > AMDGPU changes. The AMDGPU backend already uses a pattern to implement > subroutines that looks like this: > > class getWhatever<parameters> { > type ret = ...; > } > > This tends to work out in many cases because getWhatever<...>.ret is > substituted early, but there are corner cases when you push it further, > and I believe those are all fixed with the VarDefInit change I've > desc...

On Mon, Feb 19, 2018 at 11:26 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote: > Hi all, > > While working on some features for the AMDGPU backend -- specifically, > explicit address components for image intrinsics, which involves > generating both > > (a) a lot of intrinsics with different but somewhat regular parameter > types, and > > (b) the patterns to

Hi all, While working on some features for the AMDGPU backend -- specifically, explicit address components for image intrinsics, which involves generating both (a) a lot of intrinsics with different but somewhat regular parameter types, and (b) the patterns to select instructions for those intrinsics -- I got fed up with a lot of the TableGen bugs and limitations and set out to fix things.