llvm dev - Jan 2022 - Are unknown types now intentionally casual?

Given the following code:

struct Unknown;
extern struct Unknown Unknown;

struct Unknown *foo(void) {
  return &Unknown;
}

And compiling it with a recent (trunk of a few days ago) clang with default
options gives (abridged):

%struct.Unknown = type opaque

@Unknown = external dso_local global %struct.Unknown, align 1

; Function Attrs: noinline nounwind optnone uwtable
define dso_local %struct.Unknown* @foo() #0 {
entry:
  ret %struct.Unknown* @Unknown
}

Okay, so I think I understand what's going on there. Now, trying the same
input with the same compiler and adding the option -mllvm -opaque-pointers
(because opaque pointers are good; I think they are a very worthwhile
simplification):

@Unknown = external dso_local global %struct.Unknown, align 1

; Function Attrs: noinline nounwind optnone uwtable
define dso_local ptr @foo() #0 {
entry:
  ret ptr @Unknown
}

So that's mostly clear except one thing I'm not quite clear
about: %struct.Unknown is referred to, but not declared anywhere. Is that
intentional? Is the rule now intended to be that whenever a %type.name is
used that was not declared anywhere, it should be taken to be an opaque
type? (I'm fine with that if it is, just figure I better make sure.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20220109/b7c3d1fb/attachment.html>

... no, when I feed the second output as input into clang again, it objects
to the undeclared type:

(c1) C:\t>clang -mllvm -opaque-pointers 2.ll
2.ll:6:38: error: use of undefined type named 'struct.Unknown'
@Unknown = external dso_local global %struct.Unknown, align 1
                                     ^
1 error generated.

So this seems to be just a bug in this particular version of clang,
probably because the opaque pointers conversion is still a work in progress?

On Sun, Jan 9, 2022 at 4:20 AM Russell Wallace <russell.wallace at
gmail.com>
wrote:
> Given the following code:
>
> struct Unknown;
> extern struct Unknown Unknown;
>
> struct Unknown *foo(void) {
>   return &Unknown;
> }
>
> And compiling it with a recent (trunk of a few days ago) clang with
> default options gives (abridged):
>
> %struct.Unknown = type opaque
>
> @Unknown = external dso_local global %struct.Unknown, align 1
>
> ; Function Attrs: noinline nounwind optnone uwtable
> define dso_local %struct.Unknown* @foo() #0 {
> entry:
>   ret %struct.Unknown* @Unknown
> }
>
> Okay, so I think I understand what's going on there. Now, trying the
same
> input with the same compiler and adding the option -mllvm -opaque-pointers
> (because opaque pointers are good; I think they are a very worthwhile
> simplification):
>
> @Unknown = external dso_local global %struct.Unknown, align 1
>
> ; Function Attrs: noinline nounwind optnone uwtable
> define dso_local ptr @foo() #0 {
> entry:
>   ret ptr @Unknown
> }
>
> So that's mostly clear except one thing I'm not quite clear
> about: %struct.Unknown is referred to, but not declared anywhere. Is that
> intentional? Is the rule now intended to be that whenever a %type.name is
> used that was not declared anywhere, it should be taken to be an opaque
> type? (I'm fine with that if it is, just figure I better make sure.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20220109/0fc277e7/attachment.html>